Re: [PATCH] Broken NR_RESERVED_FILES
Hi, Another comment on your patch. You removed the goto used_one (probably a good idea, I hated it as well and preferred to put it into the if()) but you forgot to remove the label itself. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 64bit offsets for block devices ?
> Is there any way of getting a standardized way of doing I/O to a block > device which could handle 64bit addresses for the block number? Submit patches early into 2.5 to extend the block range ? > Don't you think that we will run into problems anyway because soon there > will be raid systems with a couple of Terrabytes of space to waste for > mp3's ;-) The limit is currently about 1Tb per block so yes it will eventually get us - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
> Reserved fd's for superuser doesn't work.
It does actually work, but remember that the concept of "reserved file
structures for superuser" is defined as "file structures to be taken from
the freelist" whereas your patch below:
> + total_free = max_files - nr_files + nr_free_files;
> + if (total_free > NR_RESERVED_FILES || (total_free && !current->euid)) {
> + if (nr_free_files) {
> + used_one:
> + f = free_filps;
> + remove_filp(f);
> + nr_free_files--;
> + new_one:
> + memset(f, 0, sizeof(*f));
> + f->f_count = 1;
> + f->f_version = ++global_event;
> + f->f_uid = current->fsuid;
> + f->f_gid = current->fsgid;
> + put_inuse(f);
> + return f;
> + }
> + /*
> + * Allocate a new one if we're below the limit.
> + */
> f = kmem_cache_alloc(filp_cache, SLAB_KERNEL);
allows one to allocate a file structure from the filp_cache slab cache if
one is a superuser. That is not a "fix" -- it is a serious re-definition
of semantics of 'freelist'. There are even books (Understanding the Linux
Kernel by Bovet et all) which describe this freelist in the current
context so your patch will require updates to the books.
Having said that, it is probably a good idea to allow superuser to
allocate new file structures... just remember that you have just
_rewritten_ get_empty_filp()'s rules completely and not "fixed" them.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Pavel Machek wrote: > > Please consider including this user space serial driver. It was writen for > > the Pele 833 RAS Server but is also usable for other serial device drivers > > in user space. > > Good, someone finally implemented this. This is going to be mandatory > if we want to support winmodems properly; also ISDN people might be > interested [to kick AT emulation out of kernel]. For winmodems you can do a pretty good job with ptys -- the pty and tty side access the same share termios structure. The new driver is a much cleaner way to the same functionality though. (Conceptually; I looked at the API summary but haven't looked at the code). -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Microsecond accuracy
Hi, How about TSC? I know this has disadvantages such as: a) not all machines have TSC b) not all machines that claim to have TSC have a usable one. c) on SMP the kernel makes a best effort to synchronize TSC but this may or may not be guaranteed d) you still need a userspace implementation to correctly map TSC cycles to (micro)seconds using various MHz-specific ratios/whatever. I think someone I know has already done this work but will let him speak if he wants to release this to public or not. other than the above, TSC (rdtsc instruction) is perfectly available to userspace applications without special privileges. And it is 64bit so it won't easily wrap around... regards, Tigran. On Thu, 7 Dec 2000, Kotsovinos Vangelis wrote: > > Is there any way to measure (with microsecond accuracy) the time of a > program execution (without using Machine Specific Registers) ? > I've already tried getrusage(), times() and clock() but they all have > 10 millisecond accuracy, even though they claim to have microsecond > acuracy. > The only thing that seems to work is to use one of the tools that measure > performanc through accessing the machine specific registers. They give you > the ability to measure the clock cycles used, but their accuracy is also > very low from what I have seen up to now. > > Thank you very much in advance > > --) Vangelis > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Broken NR_RESERVED_FILES
Reserved fd's for superuser doesn't work. Patch for 2.2 is below,
kernel 2.4.x also has this problem, fix is similar. The default
NR_RESERVED_FILES value also had to be increased (e.g. ssh, login
needs 36, ls 16, man 45 fd's, etc).
BTW, I have an updated version of my reserved VM for superuser +
improved/fixed version of Rik's out of memory killer patch for 2.2
here,
http://mlf.linux.rulez.org/mlf/ezaz/reserved_root_vm+oom_killer-5.diff
It fixes the potential deadlock when kernel threads were blocked to
try to free pages - more details about the patch are in a former
email, http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0624.html
Szaka
diff -ur linux-2.2.18pre21/fs/file_table.c linux/fs/file_table.c
--- linux-2.2.18pre21/fs/file_table.c Tue Jan 4 13:12:23 2000
+++ linux/fs/file_table.c Thu Dec 7 13:26:06 2000
@@ -71,30 +71,27 @@
{
static int old_max = 0;
struct file * f;
+ int total_free;
- if (nr_free_files > NR_RESERVED_FILES) {
- used_one:
- f = free_filps;
- remove_filp(f);
- nr_free_files--;
- new_one:
- memset(f, 0, sizeof(*f));
- f->f_count = 1;
- f->f_version = ++global_event;
- f->f_uid = current->fsuid;
- f->f_gid = current->fsgid;
- put_inuse(f);
- return f;
- }
- /*
-* Use a reserved one if we're the superuser
-*/
- if (nr_free_files && !current->euid)
- goto used_one;
- /*
-* Allocate a new one if we're below the limit.
-*/
- if (nr_files < max_files) {
+ total_free = max_files - nr_files + nr_free_files;
+ if (total_free > NR_RESERVED_FILES || (total_free && !current->euid)) {
+ if (nr_free_files) {
+ used_one:
+ f = free_filps;
+ remove_filp(f);
+ nr_free_files--;
+ new_one:
+ memset(f, 0, sizeof(*f));
+ f->f_count = 1;
+ f->f_version = ++global_event;
+ f->f_uid = current->fsuid;
+ f->f_gid = current->fsgid;
+ put_inuse(f);
+ return f;
+ }
+ /*
+* Allocate a new one if we're below the limit.
+ */
f = kmem_cache_alloc(filp_cache, SLAB_KERNEL);
if (f) {
nr_files++;
diff -ur linux-2.2.18pre21/include/linux/fs.h linux/include/linux/fs.h
--- linux-2.2.18pre21/include/linux/fs.hThu Nov 9 08:20:18 2000
+++ linux/include/linux/fs.hThu Dec 7 11:10:50 2000
@@ -51,7 +51,7 @@
extern int max_super_blocks, nr_super_blocks;
#define NR_FILE 4096 /* this can well be larger on a larger system */
-#define NR_RESERVED_FILES 10 /* reserved for root */
+#define NR_RESERVED_FILES 96 /* reserved for root */
#define NR_SUPER 256
#define MAY_EXEC 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Microsecond accuracy
Is there any way to measure (with microsecond accuracy) the time of a program execution (without using Machine Specific Registers) ? I've already tried getrusage(), times() and clock() but they all have 10 millisecond accuracy, even though they claim to have microsecond acuracy. The only thing that seems to work is to use one of the tools that measure performanc through accessing the machine specific registers. They give you the ability to measure the clock cycles used, but their accuracy is also very low from what I have seen up to now. Thank you very much in advance --) Vangelis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Thu, 7 Dec 2000, Tigran Aivazian wrote: > a) we don't hit that test because permission takes care of it (for > regulars/dirs/symlinks but here only regulars are important) omit what is in brackets but everything in email and the patch itself are valid and tested. The detail in bracket above was unimportant since the main text provided enough proof. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Wed, 6 Dec 2000, Alexander Viro wrote: > On Wed, 6 Dec 2000, Linus Torvalds wrote: > > Why remove the EROFS test? > > there, so if it's not a regular file we die before the call of permission(), > if it is and fs is readonly - we get -EROFS from permission() and die > there. In either case we don't get to the IS_RDONLY() check... just to add that I removed the immutable test for almost the same reason: a) we don't hit that test because permission takes care of it (for regulars/dirs/symlinks but here only regulars are important) b) the error returned by permission EACCES makes a lot more sense than EPERM we were trying to return. I already quotes Single UNIX v2 to explain why. Now, here is the same patch, except: a) tested under test12-pre7 b) I suggest we explain why we return EPERM for append-only files despite the fact that SuS and common sense suggest EACCES. Facts verified under FreeBSD 4.2 The rationale for being compatible with 4.4BSD on append-only but not on immutable is -- for immutable we can do the test by means of permission() fast but for append-only we would need an extra if() above permission so let's just be BSD-compatible. Alternatively, one could ignore BSD altogether and return EACCES in both. Or, one could ignore SuS altogether and return EPERM for both immutable and append-only. It is a matter of taste so... I chose something in the middle , perhaps non-intuitive but optimized for speed and the size of code. Regards, Tigran --- linux/fs/open.c Thu Oct 26 16:11:21 2000 +++ work/fs/open.c Thu Dec 7 09:06:50 2000 @@ -102,7 +102,12 @@ goto out; inode = nd.dentry->d_inode; - error = -EACCES; + /* For directories it's -EISDIR, for other non-regulars - -EINVAL */ + error = -EISDIR; + if (S_ISDIR(inode->i_mode)) + goto dput_and_out; + + error = -EINVAL; if (!S_ISREG(inode->i_mode)) goto dput_and_out; @@ -110,12 +115,9 @@ if (error) goto dput_and_out; - error = -EROFS; - if (IS_RDONLY(inode)) - goto dput_and_out; - + /* EPERM for 4.4BSD compat. EACCES would make more sense */ error = -EPERM; - if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + if (IS_APPEND(inode)) goto dput_and_out; /* @@ -163,7 +165,7 @@ goto out; dentry = file->f_dentry; inode = dentry->d_inode; - error = -EACCES; + error = -EINVAL; if (!S_ISREG(inode->i_mode) || !(file->f_mode & FMODE_WRITE)) goto out_putf; error = -EPERM; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
"[EMAIL PROTECTED]" wrote: > On 2.2.17 I had good luck with BP6. Never tried the 2.2 series with this controller - probably should get around to doing that this weekend. :S > EX: > [root@animal /root]# uptime > 3:17am up 51 days, 20:17, 2 users, load average: 0.00, 0.04, 0.02 Uptime proves nothing alas; I could get 30+ days if I wanted :S > Can you post/e-mail any additional details about the lockups. I am very > curious about this. We have a huge mosix cluster in production with BP6 > mobo's and have plans to upgrade to 2.4 as soon as an official stable > kernel is released. The problem is not one of lockups. The system in question doesn't lock; it doesn't crash; it doesn't even log anything at the time - not even APIC errors. Instead it quietly and silently corrupts exactly four bytes at a time; mostly on the last four bytes of a 4096 block... I can most easily cause the corruption by copying a large amount of known data across the disk, and then checking for differences: cp -aR /usr/src/linux /usr/src/l2 ; diff -dur /usr/src/linux /usr/src/l2 When it does corrupt in this manner, it is not so much of a concern - I can detect, delete, and recopy the corrupted file(s). What is more worrying is, what if it is quietly silently and happily corrupting other data - when I'm NOT staring at it with a paranoid concern; for example, compiling binaries; or altering large data files... As such, I cannot at this time reduce the problem to one of Software or Hardware Error; and while it is A Major Problem in my eyes; I avoid it currently by not using the hpt366 controller :) Gerard Sharp Two Penguins at 1024x768 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
USB-related lockup in test12-pre5
Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make this magically go away? I doubt it. This happened when trying to run excel under wine. Dual Celeron with CONFIG_USB_UHCI. NMI Watchdog detected LOCKUP on CPU1, registers: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00200086 eax: c12c9600 ebx: c7a383c0 ecx: c7a383c0 edx: c12c9600 esi: 0001 edi: 0001 ebp: c7f068a0 esp: c123dea8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c123d000) Stack: 0026 0001 c7a38398 c7a383c0 0001 c7a38000 c01f488e c7a383c0 ca8578be c7a383c0 00200246 c7a383c0 c7f068a0 c01ffc3e c7a383c0 c12c9600 c7a3846c c7f068a0 c7f068bc Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: f3 90 7e f8 e9 42 dc f8 ff 80 7e 24 00 f3 90 7e f8 e9 89 e7 >>EIP; c0270c21<= Trace; c01f488e Trace; ca8578be <[audio]usbout_completed+7e/c0> Trace; c01ffc3e Trace; c01ffd49 Trace; c010c800 Trace; c010ca01 Trace; c0108f50 Trace; c010af88 Trace; c0108f50 Trace; c0100018 Trace; c0108f7c Trace; c0109002 Trace; c011f47d Trace; c010ca47 Code; c0270c21 <_EIP>: Code; c0270c21<= 0: f3 90 repz nop<= Code; c0270c23 2: 7e f8 jlefffc <_EIP+0xfffc> c0270c1d Code; c0270c25 4: e9 42 dc f8 ffjmpfff8dc4b <_EIP+0xfff8dc4b> c01fe86c Code; c0270c2a 9: 80 7e 24 00 cmpb $0x0,0x24(%esi) Code; c0270c2e d: f3 90 repz nop Code; c0270c30 f: 7e f8 jle9 <_EIP+0x9> c0270c2a Code; c0270c32 11: e9 89 e7 00 00jmpe79f <_EIP+0xe79f> c027f3c0 -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Out of socket memory? (2.4.0-test11)
Daniel Walton ([EMAIL PROTECTED]) wrote:
> I've been having a problem with a high volume Linux web server. This
> particular web server used to be a FreeBSD machine and I've been trying to
> successfully make the switch for some time now. I've been trying the 2.4
> development kernels as they come out and I've been tweaking the /proc
> filesystem variables but so far nothing seems to have fixed the
> problem. The problem is that I get "Out of socket memory" errors and the
> networking locks up...
FWIW, the code that prints this is in ipv4/tcp_timer.c
and it looks like it's a DoS attack countermeasure.
Looks like you can tune it with sysctl_tcp_max_orphans, among
other things. Here's the code from test11-pre4:
/* Do not allow orphaned sockets to eat all our resources.
* This is direct violation of TCP specs, but it is required
* to prevent DoS attacks. It is called when a retransmission timeout
* or zero probe timeout occurs on orphaned socket.
*
* Criterium is still not confirmed experimentally and may change.
* We kill the socket, if:
* 1. If number of orphaned sockets exceeds an administratively configured
*limit.
* 2. If we have strong memory pressure.
*/
static int tcp_out_of_resources(struct sock *sk, int do_reset)
{
struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
int orphans = atomic_read(_orphan_count);
/* If peer does not open window for long time, or did not transmit
* anything for long time, penalize it. */
if ((s32)(tcp_time_stamp - tp->lsndtime) > 2*TCP_RTO_MAX || !do_reset)
orphans <<= 1;
/* If some dubious ICMP arrived, penalize even more. */
if (sk->err_soft)
orphans <<= 1;
if (orphans >= sysctl_tcp_max_orphans ||
(sk->wmem_queued > SOCK_MIN_SNDBUF &&
atomic_read(_memory_allocated) > sysctl_tcp_mem[2])) {
if (net_ratelimit())
printk(KERN_INFO "Out of socket memory\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Out of socket memory? (2.4.0-test11)
Daniel Walton ([EMAIL PROTECTED]) wrote:
I've been having a problem with a high volume Linux web server. This
particular web server used to be a FreeBSD machine and I've been trying to
successfully make the switch for some time now. I've been trying the 2.4
development kernels as they come out and I've been tweaking the /proc
filesystem variables but so far nothing seems to have fixed the
problem. The problem is that I get "Out of socket memory" errors and the
networking locks up...
FWIW, the code that prints this is in ipv4/tcp_timer.c
and it looks like it's a DoS attack countermeasure.
Looks like you can tune it with sysctl_tcp_max_orphans, among
other things. Here's the code from test11-pre4:
/* Do not allow orphaned sockets to eat all our resources.
* This is direct violation of TCP specs, but it is required
* to prevent DoS attacks. It is called when a retransmission timeout
* or zero probe timeout occurs on orphaned socket.
*
* Criterium is still not confirmed experimentally and may change.
* We kill the socket, if:
* 1. If number of orphaned sockets exceeds an administratively configured
*limit.
* 2. If we have strong memory pressure.
*/
static int tcp_out_of_resources(struct sock *sk, int do_reset)
{
struct tcp_opt *tp = (sk-tp_pinfo.af_tcp);
int orphans = atomic_read(tcp_orphan_count);
/* If peer does not open window for long time, or did not transmit
* anything for long time, penalize it. */
if ((s32)(tcp_time_stamp - tp-lsndtime) 2*TCP_RTO_MAX || !do_reset)
orphans = 1;
/* If some dubious ICMP arrived, penalize even more. */
if (sk-err_soft)
orphans = 1;
if (orphans = sysctl_tcp_max_orphans ||
(sk-wmem_queued SOCK_MIN_SNDBUF
atomic_read(tcp_memory_allocated) sysctl_tcp_mem[2])) {
if (net_ratelimit())
printk(KERN_INFO "Out of socket memory\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
USB-related lockup in test12-pre5
Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make this magically go away? I doubt it. This happened when trying to run excel under wine. Dual Celeron with CONFIG_USB_UHCI. NMI Watchdog detected LOCKUP on CPU1, registers: CPU:1 EIP:0010:[c0270c21] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00200086 eax: c12c9600 ebx: c7a383c0 ecx: c7a383c0 edx: c12c9600 esi: 0001 edi: 0001 ebp: c7f068a0 esp: c123dea8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c123d000) Stack: 0026 0001 c7a38398 c7a383c0 0001 c7a38000 c01f488e c7a383c0 ca8578be c7a383c0 00200246 c7a383c0 c7f068a0 c01ffc3e c7a383c0 c12c9600 c7a3846c c7f068a0 c7f068bc Call Trace: [c01f488e] [ca8578be] [c01ffc3e] [c01ffd49] [c010c800] [c010ca01] [c0108f50] [c010af88] [c0108f50] [c0100018] [c0108f7c] [c0109002] [c011f47d] [c010ca47] Code: f3 90 7e f8 e9 42 dc f8 ff 80 7e 24 00 f3 90 7e f8 e9 89 e7 EIP; c0270c21 stext_lock+4e6d/8f50 = Trace; c01f488e usb_submit_urb+1e/30 Trace; ca8578be [audio]usbout_completed+7e/c0 Trace; c01ffc3e process_urb+1de/230 Trace; c01ffd49 uhci_interrupt+b9/120 Trace; c010c800 handle_IRQ_event+60/90 Trace; c010ca01 do_IRQ+a1/100 Trace; c0108f50 default_idle+0/40 Trace; c010af88 ret_from_intr+0/20 Trace; c0108f50 default_idle+0/40 Trace; c0100018 startup_32+18/cb Trace; c0108f7c default_idle+2c/40 Trace; c0109002 cpu_idle+52/70 Trace; c011f47d do_softirq+6d/a0 Trace; c010ca47 do_IRQ+e7/100 Code; c0270c21 stext_lock+4e6d/8f50 _EIP: Code; c0270c21 stext_lock+4e6d/8f50 = 0: f3 90 repz nop= Code; c0270c23 stext_lock+4e6f/8f50 2: 7e f8 jlefffc _EIP+0xfffc c0270c1d stext_lock+4e69/8f50 Code; c0270c25 stext_lock+4e71/8f50 4: e9 42 dc f8 ffjmpfff8dc4b _EIP+0xfff8dc4b c01fe86c uhci_submit_urb+6c/2d0 Code; c0270c2a stext_lock+4e76/8f50 9: 80 7e 24 00 cmpb $0x0,0x24(%esi) Code; c0270c2e stext_lock+4e7a/8f50 d: f3 90 repz nop Code; c0270c30 stext_lock+4e7c/8f50 f: 7e f8 jle9 _EIP+0x9 c0270c2a stext_lock+4e76/8f50 Code; c0270c32 stext_lock+4e7e/8f50 11: e9 89 e7 00 00jmpe79f _EIP+0xe79f c027f3c0 tvecs+1678/e4f8 -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: HPT366 + SMP = slight corruption in 2.3.99 - 2.4.0-11
"[EMAIL PROTECTED]" wrote: On 2.2.17 I had good luck with BP6. Never tried the 2.2 series with this controller - probably should get around to doing that this weekend. :S EX: [root@animal /root]# uptime 3:17am up 51 days, 20:17, 2 users, load average: 0.00, 0.04, 0.02 Uptime proves nothing alas; I could get 30+ days if I wanted :S Can you post/e-mail any additional details about the lockups. I am very curious about this. We have a huge mosix cluster in production with BP6 mobo's and have plans to upgrade to 2.4 as soon as an official stable kernel is released. The problem is not one of lockups. The system in question doesn't lock; it doesn't crash; it doesn't even log anything at the time - not even APIC errors. Instead it quietly and silently corrupts exactly four bytes at a time; mostly on the last four bytes of a 4096 block... I can most easily cause the corruption by copying a large amount of known data across the disk, and then checking for differences: cp -aR /usr/src/linux /usr/src/l2 ; diff -dur /usr/src/linux /usr/src/l2 When it does corrupt in this manner, it is not so much of a concern - I can detect, delete, and recopy the corrupted file(s). What is more worrying is, what if it is quietly silently and happily corrupting other data - when I'm NOT staring at it with a paranoid concern; for example, compiling binaries; or altering large data files... As such, I cannot at this time reduce the problem to one of Software or Hardware Error; and while it is A Major Problem in my eyes; I avoid it currently by not using the hpt366 controller :) Gerard Sharp Two Penguins at 1024x768 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Wed, 6 Dec 2000, Alexander Viro wrote: On Wed, 6 Dec 2000, Linus Torvalds wrote: Why remove the EROFS test? there, so if it's not a regular file we die before the call of permission(), if it is and fs is readonly - we get -EROFS from permission() and die there. In either case we don't get to the IS_RDONLY() check... just to add that I removed the immutable test for almost the same reason: a) we don't hit that test because permission takes care of it (for regulars/dirs/symlinks but here only regulars are important) b) the error returned by permission EACCES makes a lot more sense than EPERM we were trying to return. I already quotes Single UNIX v2 to explain why. Now, here is the same patch, except: a) tested under test12-pre7 b) I suggest we explain why we return EPERM for append-only files despite the fact that SuS and common sense suggest EACCES. Facts verified under FreeBSD 4.2 The rationale for being compatible with 4.4BSD on append-only but not on immutable is -- for immutable we can do the test by means of permission() fast but for append-only we would need an extra if() above permission so let's just be BSD-compatible. Alternatively, one could ignore BSD altogether and return EACCES in both. Or, one could ignore SuS altogether and return EPERM for both immutable and append-only. It is a matter of taste so... I chose something in the middle , perhaps non-intuitive but optimized for speed and the size of code. Regards, Tigran --- linux/fs/open.c Thu Oct 26 16:11:21 2000 +++ work/fs/open.c Thu Dec 7 09:06:50 2000 @@ -102,7 +102,12 @@ goto out; inode = nd.dentry-d_inode; - error = -EACCES; + /* For directories it's -EISDIR, for other non-regulars - -EINVAL */ + error = -EISDIR; + if (S_ISDIR(inode-i_mode)) + goto dput_and_out; + + error = -EINVAL; if (!S_ISREG(inode-i_mode)) goto dput_and_out; @@ -110,12 +115,9 @@ if (error) goto dput_and_out; - error = -EROFS; - if (IS_RDONLY(inode)) - goto dput_and_out; - + /* EPERM for 4.4BSD compat. EACCES would make more sense */ error = -EPERM; - if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) + if (IS_APPEND(inode)) goto dput_and_out; /* @@ -163,7 +165,7 @@ goto out; dentry = file-f_dentry; inode = dentry-d_inode; - error = -EACCES; + error = -EINVAL; if (!S_ISREG(inode-i_mode) || !(file-f_mode FMODE_WRITE)) goto out_putf; error = -EPERM; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Microsecond accuracy
Is there any way to measure (with microsecond accuracy) the time of a program execution (without using Machine Specific Registers) ? I've already tried getrusage(), times() and clock() but they all have 10 millisecond accuracy, even though they claim to have microsecond acuracy. The only thing that seems to work is to use one of the tools that measure performanc through accessing the machine specific registers. They give you the ability to measure the clock cycles used, but their accuracy is also very low from what I have seen up to now. Thank you very much in advance --) Vangelis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Broken NR_RESERVED_FILES
Reserved fd's for superuser doesn't work. Patch for 2.2 is below,
kernel 2.4.x also has this problem, fix is similar. The default
NR_RESERVED_FILES value also had to be increased (e.g. ssh, login
needs 36, ls 16, man 45 fd's, etc).
BTW, I have an updated version of my reserved VM for superuser +
improved/fixed version of Rik's out of memory killer patch for 2.2
here,
http://mlf.linux.rulez.org/mlf/ezaz/reserved_root_vm+oom_killer-5.diff
It fixes the potential deadlock when kernel threads were blocked to
try to free pages - more details about the patch are in a former
email, http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0624.html
Szaka
diff -ur linux-2.2.18pre21/fs/file_table.c linux/fs/file_table.c
--- linux-2.2.18pre21/fs/file_table.c Tue Jan 4 13:12:23 2000
+++ linux/fs/file_table.c Thu Dec 7 13:26:06 2000
@@ -71,30 +71,27 @@
{
static int old_max = 0;
struct file * f;
+ int total_free;
- if (nr_free_files NR_RESERVED_FILES) {
- used_one:
- f = free_filps;
- remove_filp(f);
- nr_free_files--;
- new_one:
- memset(f, 0, sizeof(*f));
- f-f_count = 1;
- f-f_version = ++global_event;
- f-f_uid = current-fsuid;
- f-f_gid = current-fsgid;
- put_inuse(f);
- return f;
- }
- /*
-* Use a reserved one if we're the superuser
-*/
- if (nr_free_files !current-euid)
- goto used_one;
- /*
-* Allocate a new one if we're below the limit.
-*/
- if (nr_files max_files) {
+ total_free = max_files - nr_files + nr_free_files;
+ if (total_free NR_RESERVED_FILES || (total_free !current-euid)) {
+ if (nr_free_files) {
+ used_one:
+ f = free_filps;
+ remove_filp(f);
+ nr_free_files--;
+ new_one:
+ memset(f, 0, sizeof(*f));
+ f-f_count = 1;
+ f-f_version = ++global_event;
+ f-f_uid = current-fsuid;
+ f-f_gid = current-fsgid;
+ put_inuse(f);
+ return f;
+ }
+ /*
+* Allocate a new one if we're below the limit.
+ */
f = kmem_cache_alloc(filp_cache, SLAB_KERNEL);
if (f) {
nr_files++;
diff -ur linux-2.2.18pre21/include/linux/fs.h linux/include/linux/fs.h
--- linux-2.2.18pre21/include/linux/fs.hThu Nov 9 08:20:18 2000
+++ linux/include/linux/fs.hThu Dec 7 11:10:50 2000
@@ -51,7 +51,7 @@
extern int max_super_blocks, nr_super_blocks;
#define NR_FILE 4096 /* this can well be larger on a larger system */
-#define NR_RESERVED_FILES 10 /* reserved for root */
+#define NR_RESERVED_FILES 96 /* reserved for root */
#define NR_SUPER 256
#define MAY_EXEC 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsecond accuracy
Hi, How about TSC? I know this has disadvantages such as: a) not all machines have TSC b) not all machines that claim to have TSC have a usable one. c) on SMP the kernel makes a best effort to synchronize TSC but this may or may not be guaranteed d) you still need a userspace implementation to correctly map TSC cycles to (micro)seconds using various MHz-specific ratios/whatever. I think someone I know has already done this work but will let him speak if he wants to release this to public or not. other than the above, TSC (rdtsc instruction) is perfectly available to userspace applications without special privileges. And it is 64bit so it won't easily wrap around... regards, Tigran. On Thu, 7 Dec 2000, Kotsovinos Vangelis wrote: Is there any way to measure (with microsecond accuracy) the time of a program execution (without using Machine Specific Registers) ? I've already tried getrusage(), times() and clock() but they all have 10 millisecond accuracy, even though they claim to have microsecond acuracy. The only thing that seems to work is to use one of the tools that measure performanc through accessing the machine specific registers. They give you the ability to measure the clock cycles used, but their accuracy is also very low from what I have seen up to now. Thank you very much in advance --) Vangelis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] New user space serial port driver
Pavel Machek wrote: Please consider including this user space serial driver. It was writen for the Pele 833 RAS Server but is also usable for other serial device drivers in user space. Good, someone finally implemented this. This is going to be mandatory if we want to support winmodems properly; also ISDN people might be interested [to kick AT emulation out of kernel]. For winmodems you can do a pretty good job with ptys -- the pty and tty side access the same share termios structure. The new driver is a much cleaner way to the same functionality though. (Conceptually; I looked at the API summary but haven't looked at the code). -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
Reserved fd's for superuser doesn't work.
It does actually work, but remember that the concept of "reserved file
structures for superuser" is defined as "file structures to be taken from
the freelist" whereas your patch below:
+ total_free = max_files - nr_files + nr_free_files;
+ if (total_free NR_RESERVED_FILES || (total_free !current-euid)) {
+ if (nr_free_files) {
+ used_one:
+ f = free_filps;
+ remove_filp(f);
+ nr_free_files--;
+ new_one:
+ memset(f, 0, sizeof(*f));
+ f-f_count = 1;
+ f-f_version = ++global_event;
+ f-f_uid = current-fsuid;
+ f-f_gid = current-fsgid;
+ put_inuse(f);
+ return f;
+ }
+ /*
+ * Allocate a new one if we're below the limit.
+ */
f = kmem_cache_alloc(filp_cache, SLAB_KERNEL);
allows one to allocate a file structure from the filp_cache slab cache if
one is a superuser. That is not a "fix" -- it is a serious re-definition
of semantics of 'freelist'. There are even books (Understanding the Linux
Kernel by Bovet et all) which describe this freelist in the current
context so your patch will require updates to the books.
Having said that, it is probably a good idea to allow superuser to
allocate new file structures... just remember that you have just
_rewritten_ get_empty_filp()'s rules completely and not "fixed" them.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
Hi, Another comment on your patch. You removed the goto used_one (probably a good idea, I hated it as well and preferred to put it into the if()) but you forgot to remove the label itself. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 64bit offsets for block devices ?
Is there any way of getting a standardized way of doing I/O to a block device which could handle 64bit addresses for the block number? Submit patches early into 2.5 to extend the block range ? Don't you think that we will run into problems anyway because soon there will be raid systems with a couple of Terrabytes of space to waste for mp3's ;-) The limit is currently about 1Tb per block so yes it will eventually get us - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Thu, 7 Dec 2000, Tigran Aivazian wrote: The rationale for being compatible with 4.4BSD on append-only but not on immutable is -- for immutable we can do the test by means of permission() fast but for append-only we would need an extra if() above permission so let's just be BSD-compatible. Alternatively, one could ignore BSD altogether and return EACCES in both. Or, one could ignore SuS altogether and return EPERM for both immutable and append-only. It is a matter of taste so... I chose something in the middle , perhaps non-intuitive but optimized for speed and the size of code. Big, loud "yuck". The first rule of optimization: don't. I agree that in the current code test for immutable is dead. However, the rationale above is a BS. The path is nowhere near time-critical ones. Moreover, it doesn't make the code simpler. History: 4.4BSD treats immutable and append-only the same way it treats removal from sticky-bit directories, etc. I.e. consistenly returns -EPERM. Yes, on access(), open() for write, directory operations, yodda, yodda. So correct solution may very well be to change the return value of permission(9). FWIW, MAY_TRUNCATE might be a good idea - notice that knfsd already has something like that. It makes sense for directories, BTW - having may_delete() drop the IS_APPEND() test and pass MAY_TRUNCATE to permission() instead. looking at the truncate(2) manpage Oh, lovely - where the hell had the following come from? % man truncate ... EINVAL The pathname contains a character with the high- order bit set. ... Andries, would you mind removing that, erm, statement? I'm curious about its genesis - AFAIK we had 8bit-clean namei for ages (quite possibly since 0.01). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1, rebuilt, and I got a test11-ac1 kernel which works with KDE 2.0 and sound. Excellent, that really narrows it down. Once 2.2.18 is out I will try and get to the bottom of this - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Tigran Aivazian wrote: On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote: Reserved fd's for superuser doesn't work. It does actually work, What do you mean under "work"? I meant user apps are able to exhaust fd's completely and none is left for superuser. but remember that the concept of "reserved file structures for superuser" is defined as "file structures to be taken from the freelist" Yes, in this sense it works and it's also very close to unhelpfulness. whereas your patch below: [...] allows one to allocate a file structure from the filp_cache slab cache if one is a superuser. Or one is user and didn't hit yet the reserved fd's (and of course superuser aren't able to allocate more then max_files). Szaka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: YMF PCI - thanks, glitches, patches (fwd)
The Linux-sound list appears to be dead (I don't see my message in http://www.kernelnotes.org/lnxlists/linux-sound/), so I'm sending to the [EMAIL PROTECTED] is alive and well however. An additional problem is that opl3 cannot find the device unless I load and unload the old driver (ymf_sb). Probably the new driver should put the OPL3 interface to the legacy mode if it cannot handle it directly. Probably Dec 5 18:08:16 fonzie kernel: ymfpci: ioctl cmd 0x5401 Dec 5 18:08:50 fonzie last message repeated 9 times Just debugging this is fine $ play spinout.wav sox: Unable to set audio speed to 5512 (set to 8000) 8Khz is the lower limit right now the way the board is driven. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Thu, 7 Dec 2000, Alexander Viro wrote: So correct solution may very well be to change the return value of permission(9). FWIW, MAY_TRUNCATE might be a good idea - notice that knfsd already has something like that. It makes sense for directories, BTW - having may_delete() drop the IS_APPEND() test and pass MAY_TRUNCATE to permission() instead. Alexander, The above sounds like an excellent idea (MAY_TRUNCATE specifically!) but please understand that I simply wanted to minimize the amount of fundamental code changes. Yes, it would be much cleaner to have a MAY_XXX which groups little specific tests together for every scenario, e.g. for truncate(). So, I wasn't suggesting BS as the "best thing for all times" but merely as the "best thing at the moment without changing too much and yet not leaving dead code in there and not adding too much new code". Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
64 bit s390 and 2.4.0-test11 (was Memory management bug)
Hi,
good news (at least for us): linux on the 64 bit S/390 (aka zServer)
is now running pretty stable. Our implementation of ptep_get_and_clear
didn't clear the pte if the invalid bit was already set. But a swapped
page has the invalid bit set too and in that case we didn't clear the
pte. That did cause the BUG() in swap_state.c:60.
With this new backend in mind I'd like to suggest two small changes
for the common code.
1) move establish_pte to the architecture dependent folders. Our
implementation looks like this:
static inline void ptep_invalidate_and_flush(pte_t *ptep, unsigned long
addr)
{
if (!(pte_val(*ptep) _PAGE_INVALID))
__asm__ __volatile__ ("ipte %0,%1" : : "a" (ptep), "a"
(addr));
}
static inline void establish_pte(struct vm_area_struct * vma,
unsigned long address,
pte_t *page_table, pte_t entry)
{
ptep_invalidate_and_flush(page_table, address);
set_pte(page_table, entry);
}
The question I face at the moment is: where is the right place in
include/asm for establish_pte. I added it to include/asm-generic/pgtable.h
and include/asm-i386/pgtable.h but I now face the problem that the
default implementation has a call to flush_tlb_page and that is defined
in pgalloc.h. I added an #include asm/pgalloc.h but I fear that this
could
cause compile errors. For details see establish_pte.diff.
2) add a check for EI_CLASS in the binfmt_elf loader. We will use the
same EM_S390 for 31 bit and 64 bit binaries. The distinction is done
by means of the EI_CLASS byte in the ELF header. See binfmt_elf.diff
blue skies,
Martin
Linux/390 Design Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: [EMAIL PROTECTED]
(See attached file: establish_pte.diff)(See attached file: binfmt_elf.diff)
establish_pte.diff
binfmt_elf.diff
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
Reserved fd's for superuser doesn't work.
It does actually work,
What do you mean under "work"? I meant user apps are able to
exhaust fd's completely and none is left for superuser.
really? how did you manage to do that? On a 2.4.0-test12-pre7 system I
cannot reproduce the behaviour you describe. I.e. at least
NR_RESERVED_FILES (which I agree with you should be increased!) are left
to superuser processes whilst the user processes are denied.
How exactly are you reproducing this? I wrote a simple while (1)
{open("/dev/null", 0); } program and run many instances of it as user. At
some stage user starts failing but superuser happily draws from the
freelist. Of course, the superuser cannot start complex programs which
require many descriptos but that is entirely the issues of
NR_RESERVED_FILES being too small on which I totally agree with you.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Out of socket memory? (2.4.0-test11)
On Wed, Dec 06, 2000 at 10:56:32PM -0600, Daniel Walton wrote: Hello, I've been having a problem with a high volume Linux web server. This particular web server used to be a FreeBSD machine and I've been trying to successfully make the switch for some time now. I've been trying the 2.4 development kernels as they come out and I've been tweaking the /proc filesystem variables but so far nothing seems to have fixed the problem. The problem is that I get "Out of socket memory" errors and the networking locks up. Sometimes the server will go for weeks without You should probably first find out what and why is generating these messages. It isn't the kernel. When the web server is generating when a send blocks then it is badly broken. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Wed, 6 Dec 2000, Mike A. Harris wrote: Which ethernet module works with this card? 2.2.17 kernel Should be the rtl8139 driver. Regards, Jim -- Mike A. Harris - Linux advocate - Open source advocate This message is copyright 2000, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- -- James Bourne, Web Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ab.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
I think we need few ioctl calls: get + set media (int argument),
get + set speed (probably two - RX and TX), etc.
In my 2.4 HDLC stuff - to be published :-( - there something like that
(in private ioctl range, of course).
I think we are agreeing
I'm saying use something like
struct
{
u16 media_group;
union
{
struct hdlc_physical ...
struct hdlc_bitstream
struct hdlc_protocol
struct fr_protocol
struct eth_physical
struct atm_physical
struct dsl_physical
struct dsl_bitstream
struct tr_physical
struct wireless_physical
struct wireless_80211
struct wireless_auth
} config;
}
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsecond accuracy
On Thu, 7 Dec 2000, Tigran Aivazian wrote: Hi, How about TSC? I know this has disadvantages such as: a) not all machines have TSC while we are on this subject, please let me emphasize that you should _not_ be using cpuid instruction to detect the presence of TSC but should parse the /proc/cpuinfo file. There are many valid reasons why Linux's idea of TSC presence may not be the same as hardware's (cpuid instruction) idea. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
Alan Cox wrote:
I think we need few ioctl calls: get + set media (int argument),
get + set speed (probably two - RX and TX), etc.
In my 2.4 HDLC stuff - to be published :-( - there something like that
(in private ioctl range, of course).
I think we are agreeing
I'm saying use something like
struct
{
u16 media_group;
union
{
struct hdlc_physical ...
struct hdlc_bitstream
struct hdlc_protocol
struct fr_protocol
struct eth_physical
Not yet another one for eth... We now have ethtool for this. And a
generic netdevice::set_config wrapper can be created that simply calls
the ethtool ioctl with the proper info and locking.
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft| It's an old Jedi mind trick.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre24 ooops
Hi, Running both of 2.2.18pre21 and pre24 casues this ooops with mpegp when it tries to produce sound (with -nosound option, it's okey). mpegp is out mpeg player based on libac3,libmpeg2,mpg123,libvo. It can be found at ftp://esp-team.scene.hu/esp-team/linux/MPlayer/ Problem occured when I tried to play matrix.vob, which includes 48Khz stereo auido (ftp://terminal.hu/matrix.vob). Output of lspci and kernel configuration file are attached. The player got sigsegv, and the meesage found in syslog translated with ksymoops is the following (devide error: ): ksymoops 2.3.4 on i686 2.2.18pre24. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.18pre24/ (default) -m /boot/System.map-2.2.18pre24 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in System.map. Ignoring ksyms_base entry Dec 7 14:25:50 vega kernel: CPU:0 Dec 7 14:25:50 vega kernel: EIP: 0010:[eepro100:__insmod_eepro100_O/lib/modules/2.2.18pre24/net/eepro100.o_+-75593/96] Dec 7 14:25:50 vega kernel: EFLAGS: 00210046 Dec 7 14:25:50 vega kernel: eax: ebx: c66dfce0 ecx: edx: Dec 7 14:25:50 vega kernel: esi: edi: c66dfcc0 ebp: 00200246 esp: c30e3eac Dec 7 14:25:50 vega kernel: ds: 0018 es: 0018 ss: 0018 Dec 7 14:25:50 vega kernel: Process mpegp (pid: 549, process nr: 74, stackpage=c30e3000) Dec 7 14:25:50 vega kernel: Stack: c66dfcc0 00200246 03e6 c3126b60 0003 c8018eff c66dfcc0 c66dfcc0 Dec 7 14:25:50 vega kernel:c756dc00 00200246 0400 000a 000d bb80 Dec 7 14:25:50 vega kernel:c7a6c6c0 0004 c32893f8 c012f57e c3126b60 Dec 7 14:25:50 vega kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.2.18pre24/net/eepro100.o_+-73985/96] [do_select+274/512] [eepro100:__insmod_eepro100_O/lib/modules/2.2.18pre24/net/eepro100.o_+-77357/96] [sys_select+881/1176] [system_call+52/56] Dec 7 14:25:50 vega kernel: Code: f7 f6 89 d5 89 4b 1c 01 6b 28 80 7b 05 01 0f 85 a8 00 00 00 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: f7 f6 div%esi,%eax Code; 0002 Before first symbol 2: 89 d5 mov%edx,%ebp Code; 0004 Before first symbol 4: 89 4b 1c mov%ecx,0x1c(%ebx) Code; 0007 Before first symbol 7: 01 6b 28 add%ebp,0x28(%ebx) Code; 000a Before first symbol a: 80 7b 05 01 cmpb $0x1,0x5(%ebx) Code; 000e Before first symbol e: 0f 85 a8 00 00 00 jnebc _EIP+0xbc 00bc Before first symbol 2 warnings issued. Results may not be reliable. - Gabor -- ---[ Gbor Lnrt ][ Vivendi Telecom Hungary ]---[ [EMAIL PROTECTED] ]--- U have 8 bit computer or chip of them and it's unused or to be sold? Call me! ---[ +36 30 2270823 ] LGB ---[ Linux/UNIX/8bit 4ever ]- 00:00.0 Host bridge: Intel Corporation 82810E GMCH [Graphics Memory Controller Hub] (rev 03) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 00:01.0 VGA compatible controller: Intel Corporation 82810E CGC [Chipset Graphics Controller] (rev 03) (prog-if 00 [VGA]) Subsystem: Compaq Computer Corporation: Unknown device b1c1 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin A routed to IRQ 11 Region 0: Memory at 4400 (32-bit, prefetchable) Region 1: Memory at 4040 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Bus: primary=00, secondary=01,
Re: 2.4.0-test12-pre4 + cs46xx + KDE 2.0 = frozen system
On Thursday 07 December 2000 06:28, Alan Cox wrote: I copied the cs46xx.c driver from 2.4.0-test11 to 2.4.0-test11-ac1, rebuilt, and I got a test11-ac1 kernel which works with KDE 2.0 and sound. Excellent, that really narrows it down. Once 2.2.18 is out I will try and get to the bottom of this Linus Torvalds wrote: The only reason for this pre7 is to resolve some warring patches in the cs46xx driver. It looks like cs46xx version 1.10 is a winner. Crystal 4280/461x + AC97 Audio, version 1.10, 07:08:39 Dec 7 2000 cs461x: Card found at 0xf8ffe000 and 0xf8e0, IRQ 18 cs461x: Unknown card (1028:0096) at 0xf8ffe000/0xf8e0, IRQ 18 ac97_codec: AC97 Audio codec, id: 0x4352:0x5914 (Unknown) The cs46xx driver in test12-pre7 by Nils Faerber, Thomas Woller, et al works great with my troublesome Dell 420. I'm now listening to music on the CD, running KDE 2.0 with the machine booted up on 2.4.0-test12-pre7. Many thanks to all who helped with this. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
struct hdlc_protocol struct fr_protocol struct eth_physical Not yet another one for eth... We now have ethtool for this. And a generic netdevice::set_config wrapper can be created that simply calls the ethtool ioctl with the proper info and locking. There I disagree. I would do it the other way up. Post 2.4 you make the ethtool ioctl simply build an eth_physical and run in that way. Right now the ethtool stuff is a bit hackish and cannot handle upcoming real world situations such as setting the cryptokey for onboard crypto on ethernet cards, or handling devices that present themselves as ethernet but are not at the physical layer being remotely honest about it. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
related to pthread
Hi I am trying to write a multithreaded tcp/ip daemon using the pthread interface. The server compiles well but during an exec it gives the following error message : "Pthread internal error : message : __libc__reinit() failed" and creates a core dump. I would highly appreciate any help. Rajiv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Thu, 7 Dec 2000, Alexander Viro wrote: On Thu, 7 Dec 2000, Tigran Aivazian wrote: The rationale for being compatible with 4.4BSD on append-only but not on immutable is -- for immutable we can do the test by means of permission() fast but for append-only we would need an extra if() above permission so let's just be BSD-compatible. Alternatively, one could ignore BSD altogether and return EACCES in both. Or, one could ignore SuS altogether and return EPERM for both immutable and append-only. It is a matter of taste so... I chose something in the middle , perhaps non-intuitive but optimized for speed and the size of code. So correct solution may very well be to change the return value of permission(9). FWIW, MAY_TRUNCATE might be a good idea - notice that knfsd already has something like that. It makes sense for directories, BTW - having may_delete() drop the IS_APPEND() test and pass MAY_TRUNCATE to permission() instead. Ok, so you agree with me (I ignore your comment on "BS" because it would imply that your own suggestion is BS too and that is not nice) that one of the three alternatives must be chosen. Which one? You have not specified yet. So far you only said that a different implementation, i.e. a different place to put the checks, is preferrable. Which of these three you think is a good idea: a) be 4.4BSD-compatible and return EPERM for both immutable and append-only b) be SuSv2-compatible and return EACCES for both immutable and append-only c) be half-compatible with BSD and half-compatible with SuS but with minimum changes to current code I understand and agree that c) is not a very good idea. Then, a) or b)? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
related to pthread
Hi I am trying to write a multithreaded tcp/ip daemon using the pthread interface. The server compiles well but during an exec it gives the following error message : "Pthread internal error : message : __libc__reinit() failed" and creates a core dump. I would highly appreciate any help. Rajiv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre7
Linus Torvalds writes: - me: UHCI drivers really need to enable bus mastering. But it'll already be turned on if pci_assign_unassigned_resources() is called. This calls pdev_enable_device for every single device, which turns on the bus master bit in the PCI command register. Is it intentional that pci_assign_unassigned_resources should: 1. enable all devices? 2. enable bus master on all devices? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
getcwd() returning -ENOENT???
Hi, Can someone explain why I'm seeing the following on test12-pre7: bash# /bin/pwd /bin/pwd: cannot get current directory: No such file or directory bash# vdir /proc/self/. ... lrwxrwxrwx1 root root 0 Dec 7 14:52 cwd - /net/raistlin/raistlin-v2.4/linux-ebsa285 (deleted) ... lrwxrwxrwx1 root root 0 Dec 7 14:52 root - / ... bash# vdir ... complete listing of directory ... bash# cat /proc/mounts /dev/root / ext2 rw,noatime 0 0 /proc /proc proc rw 0 0 /dev/hda3 /var ext2 rw,nodiratime 0 0 /dev/hda5 /usr ext2 rw,noatime 0 0 /dev/hda6 /home ext2 rw 0 0 none /dev/pts devpts rw 0 0 none /dev/shm shm rw 0 0 automount(pid482) /net/flint autofs rw 0 0 automount(pid499) /net/raistlin autofs rw 0 0 raistlin:/usr/src/v2.4 /net/raistlin/raistlin-v2.4 nfs rw,v2,rsize=4096,wsize=4096,hard,udp,lock,addr=raistlin 0 0 Rebooting the machine and trying again caused this weirdness to disappear. First time around, the network wasn't initially available when autofs started. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Thu, 7 Dec 2000, Tigran Aivazian wrote: yet. So far you only said that a different implementation, i.e. a different place to put the checks, is preferrable. -EPERM returned by permission() if we ask for write access to immutable. Al, currently walking through the /usr/share/man/man2 and swearing silently... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The horrible hack from hell called A20
Linus Torvalds wrote:
On Wed, 6 Dec 2000, Miles Lane wrote:
Here is what goes wrong:
Dec 6 04:21:32 agate kernel: eth0: Host error, FIFO diagnostic register .
But it continues to work, right?
I bet that your ethernet card is just unhappy that it couldn't get DMA in
time, because the bus was so busy. Many of the busmastering ethernet
devices will start the packet send early, happy in the knowledge that
they'll usually have plenty of time to DMA the data by the time they need
it.
This works fine most of the time, but if you have a busy PCI bus and
you're doing things over a (potentially slow) PCI bridge like the Cardbus
bridge, you're taking chances. And sometimes those chances do not work out
ok.. Especially if you have slow memory, which most laptops have.
I suspect that the worst result of this is just a noisy driver: both on
the network (runt packets) and on the console. And it obviously will cause
performance to suffer too, due to retransmitting packets that failed,
and/or losing packets.
There may be some rule for the threshold for sending packets or something
else to make this happen less, so this is probably tweakable. But it
doesn't sound deadly (unless the driver causes this to result in a dead
network - does it?)
We initialise the 3com NICs so that the DMA of Tx frames doesn't
commence until 1536 free bytes are available in the Tx FIFO. I assume
this is to make the most of the NIC's ability to bus-master-transfer an
entire frame in one slurp. But this is irrelevant.
We initialise the NIC so it starts putting data on the wire after 128
bytes are in the Tx FIFO. So yes, there is an opportunity for another
bus master to interrupt the slurp and to hold the bus for so long that
the NIC gets a TX underrun. But surely not by just wiggling the mouse
around?
I have seen just one report of a person getting Tx underruns. The
driver recovered OK. But Miles is reporting "Host error". This is
different. The 3com datasheet says:
This bit is set when a catastrophic error related to the bus
interface occurs.
The errors that set this bit are PCI target abort and PCI master
abort.
This bis is cleared by issuing the GlobalReset command...
This is a very rare problem. Trolling the vortex archives comes up
with a few comments from Das Nicmeisters:
Donald Becker write:
Another PCMCIA setup bug, except this one is much harder to track down.
The CardBus bridge chip isn't configured correctly.
This is a real bus problem, not a false report.
David Hinds wrote:
I've gotten a few reports of these PCI bus errors. They have indeed
been very hard to track down, since they are specific to particular
hardware combinations, and I've never been able to reproduce them.
Donald Becker wrote:
I've gotten this error on my Vaio 505TR, but I've never been able to
reproduce it when I'm ready to observe it.
Miles, could you please apply the below patch? It'll give us a
little more info about the PCI error. Bit 31 of `bus status' is
MasterAbort and bit 30 is TargetAbort.
Also, you can disable the start-tx-after-128-bytes feature by uncommenting
// wait_for_completion(dev, SetTxStart|0x07ff);
near the end of vortex_up(). With this change the NIC won't start
transmitting until it has the entire frame onboard. It shouldn't make
any difference (hah).
This does look like a Cardbus bridge problem.
--- linux-2.4.0-test12-pre7/drivers/net/3c59x.c Tue Nov 21 20:11:20 2000
+++ linux-akpm/drivers/net/3c59x.c Fri Dec 8 02:24:11 2000
@@ -203,7 +203,7 @@
#include linux/delay.h
static char version[] __devinitdata =
-"3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others.
http://www.scyld.com/network/vortex.html " "$Revision: 1.102.2.46 $\n";
+"3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others.
+http://www.scyld.com/network/vortex.html " "$Revision: 1.102.2.40 $\n";
MODULE_AUTHOR("Donald Becker [EMAIL PROTECTED]");
MODULE_DESCRIPTION("3Com 3c59x/3c90x/3c575 series Vortex/Boomerang/Cyclone driver");
@@ -843,10 +843,15 @@
{
int rc;
- rc = vortex_probe1 (pdev, pci_resource_start (pdev, 0), pdev-irq,
- ent-driver_data, vortex_cards_found);
- if (rc == 0)
- vortex_cards_found++;
+ /* wake up and enable device */
+ if (pci_enable_device (pdev)) {
+ rc = -EIO;
+ } else {
+ rc = vortex_probe1 (pdev, pci_resource_start (pdev, 0), pdev-irq,
+ ent-driver_data, vortex_cards_found);
+ if (rc == 0)
+ vortex_cards_found++;
+ }
return rc;
}
@@ -863,7 +868,7 @@
struct vortex_private *vp;
int option;
unsigned int eeprom[0x40], checksum = 0;/* EEPROM contents */
- int i;
+ int i, step;
struct net_device *dev;
static int printed_version;
Re: getcwd() returning -ENOENT???
On Thu, 7 Dec 2000, Russell King wrote: Hi, Can someone explain why I'm seeing the following on test12-pre7: bash# /bin/pwd /bin/pwd: cannot get current directory: No such file or directory Directory is unhashed. Normally it means that sucker had been deleted. bash# vdir /proc/self/. ... lrwxrwxrwx1 root root 0 Dec 7 14:52 cwd - /net/raistlin/raistlin-v2.4/linux-ebsa285 (deleted) Ditto. ... lrwxrwxrwx1 root root 0 Dec 7 14:52 root - / ... bash# vdir ... complete listing of directory ... Which means that it is _not_ deleted. Looks like it had been invalidated for some reason. Try to reproduce that on -test10 - that should be before NFS changes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Microsecond accuracy
Followup to: [EMAIL PROTECTED] By author:Tigran Aivazian [EMAIL PROTECTED] In newsgroup: linux.dev.kernel while we are on this subject, please let me emphasize that you should _not_ be using cpuid instruction to detect the presence of TSC but should parse the /proc/cpuinfo file. There are many valid reasons why Linux's idea of TSC presence may not be the same as hardware's (cpuid instruction) idea. Unfortunately the most important instance of the in-kernel flag -- the global one in the somewhat misnamed boot_cpu_data.x86_features -- isn't actually readable in the /proc/cpuinfo file. It is perfectly possible (e.g. the "notsc" option) for ALL the CPUs to report this capability, but the global capability to still be off. I would like to have exported the global capabilities into /proc/cpuinfo, but I'm worried about breaking software (the "flags" versus "features" issue was bad enough -- unfortunately, in cases like this, there probably is no "good" solution.) -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
again. The failed logic is also clear from the kernel code [user
happily allocates when freelist NR_RESERVED_FILES].
is it clear to you? it is not clear to me, or rather the opposite seems
clear. This is what the code looks like (in 2.4):
struct file * get_empty_filp(void)
{
static int old_max = 0;
struct file * f;
file_list_lock();
if (files_stat.nr_free_files NR_RESERVED_FILES) {
used_one:
f = list_entry(free_list.next, struct file, f_list);
list_del(f-f_list);
files_stat.nr_free_files--;
so, a normal user is only allowed to allocate from the freelist when the
number of elements on the freelist is NR_RESERVED_FILES. I do not see
how you are able to take elements from the freelist when the number is
NR_RESERVED_FILES unless you are a super-user, i.e. current-euid == 0.
Btw, while you are there (in 2.2 kernel) you may want to fix the
/proc/sys/fs/file-nr -- it is broken because it assumes that nr_files,
nr_free_files, max_files are allocated by the compiler at consecutive
addresses. I have fixed this for 2.4 ages ago but couldn't be bothered
with 2.2.x...
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
attempt to access beyond end of device
ll_rw_blk.c: generic_make_request() contains the following code:
if (maxsector count || maxsector - count sector) {
bh-b_state = (1 BH_Lock) | (1 BH_Mapped);
if (blk_size[major][MINOR(bh-b_rdev)]) {
/* This may well happen - the kernel calls bread()
without checking the size of the device, e.g.,
when mounting a device. */
printk(KERN_INFO
"attempt to access beyond end of device\n");
printk(KERN_INFO "%s: rw=%d, want=%d, limit=%d\n",
kdevname(bh-b_rdev), rw,
(sector + count)1,
blk_size[major][MINOR(bh-b_rdev)]);
}
bh-b_end_io(bh, 0);
return;
}
That means that if blk_size[major][MINOR(bh-b_rdev)] == 0, the request
is canceled but no message is printed. Shouldn't there be a warning message?
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
again. The failed logic is also clear from the kernel code [user
happily allocates when freelist NR_RESERVED_FILES].
is it clear to you? it is not clear to me, or rather the opposite seems
clear. This is what the code looks like (in 2.4):
struct file * get_empty_filp(void)
{
static int old_max = 0;
struct file * f;
file_list_lock();
if (files_stat.nr_free_files NR_RESERVED_FILES) {
used_one:
f = list_entry(free_list.next, struct file, f_list);
list_del(f-f_list);
files_stat.nr_free_files--;
so, a normal user is only allowed to allocate from the freelist when the
number of elements on the freelist is NR_RESERVED_FILES. I do not see
how you are able to take elements from the freelist when the number is
NR_RESERVED_FILES unless you are a super-user, i.e. current-euid == 0.
Read the whole get_empty_filp function, especially this part, note the
goto new_one below and the part you didn't include above [from
the new_one label],
if (files_stat.nr_files files_stat.max_files) {
file_list_unlock();
f = kmem_cache_alloc(filp_cachep, SLAB_KERNEL);
file_list_lock();
if (f) {
files_stat.nr_files++;
goto new_one;
}
Btw, while you are there (in 2.2 kernel) you may want to fix the
Sorry, no time.
Szaka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[Fwd: 2.4.0-test12-pre7]
From: Russell King [mailto:[EMAIL PROTECTED]] Linus Torvalds writes: - me: UHCI drivers really need to enable bus mastering. But it'll already be turned on if pci_assign_unassigned_resources() is called. This calls pdev_enable_device for every single device, which turns on the bus master bit in the PCI command register. Is it intentional that pci_assign_unassigned_resources should: 1. enable all devices? 2. enable bus master on all devices? Russell beat me to this question (must have something to do with that .uk location). I think that Linus's patch is correct and that pci/setup_res.c::pdev_enable_device() shouldn't be doing this: /* ??? Always turn on bus mastering. If the device doesn't support it, the bit will go into the bucket. */ cmd |= PCI_COMMAND_MASTER; First, the ??? makes it iffy. Second, if the device doesn't support it, OK, but if the device does support bus mastering and the device has been programmed from a previous kernel/driver bootup (i.e., the device isn't reset by a soft boot), then the device still knows some memory addresses to DMA into, but it shouldn't be using those. This is addressed in a Word .doc file at www.pcisig.com/developers/docs/ : "Warm Boot on PCI Machines". The short summary is that soft reset should disable bus mastering and not re-enable it. This doc says that device drivers (or expansion ROM code) are responsible for setting the bus master bit. Third, removing this will help find drivers that don't do pci_set_master() when they should (like UHCI HCDs). :( ~Randy -- ___ |randy.dunlap_at_intel.com503-677-5408| |NOTE: Any views presented here are mine alone| | may not represent the views of my employer.| --- From: Russell King [mailto:[EMAIL PROTECTED]] Linus Torvalds writes: - me: UHCI drivers really need to enable bus mastering. But it'll already be turned on if pci_assign_unassigned_resources() is called. This calls pdev_enable_device for every single device, which turns on the bus master bit in the PCI command register. Is it intentional that pci_assign_unassigned_resources should: 1. enable all devices? 2. enable bus master on all devices? Russell beat me to this question (must have something to do with that .uk location). I think that Linus's patch is correct and that pci/setup_res.c::pdev_enable_device() shouldn't be doing this:
Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Thu, Dec 07, 2000 at 08:23:59AM -0500, Alexander Viro wrote: looking at the truncate(2) manpage Oh, lovely - where the hell had the following come from? % man truncate ... EINVAL The pathname contains a character with the high- order bit set. ... Andries, would you mind removing that, erm, statement? I'm curious about its genesis - AFAIK we had 8bit-clean namei for ages (quite possibly since 0.01). I removed it in man-pages-1.30. Apparently you have an older version. (1.31 has been released; expect 1.32 soon) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Why is double_fault serviced by a trap gate?
Why is double_fault serviced by a trap gate? The problem with this is that any double-fault caused by a stack-fault, which is the usual reason, becomes a triple-fault. And a triple-fault results in a processor reset or shutdown making the fault damn near impossible to get any information on. Oughtn't the double-fault exception handler be serviced by a task gate? And similarly the NMI handler in case the NMI is on the current stack page frame? Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
Read the whole get_empty_filp function, especially this part, note the
goto new_one below and the part you didn't include above [from
the new_one label],
if (files_stat.nr_files files_stat.max_files) {
file_list_unlock();
f = kmem_cache_alloc(filp_cachep, SLAB_KERNEL);
file_list_lock();
if (f) {
files_stat.nr_files++;
goto new_one;
}
I have read the whole function, including the above code, of course. The
new_one label has nothing to do with freelists -- it adds the file to the
anon_list, where the new arrivales from the slab cache go. The goto
new_one above is there simply to initialize the structure with sane
initial values
So, the normal user _cannot_ take a file structure from the freelist
unless it contains more than NR_RESERVED_FILE entries. Please read the
whole function and see it for yourself.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Microsecond accuracy
On 7 Dec 2000, H. Peter Anvin wrote: Unfortunately the most important instance of the in-kernel flag -- the global one in the somewhat misnamed boot_cpu_data.x86_features -- isn't actually readable in the /proc/cpuinfo file. It is perfectly possible (e.g. the "notsc" option) for ALL the CPUs to report this capability, but the global capability to still be off. Hmm, I recall I implemented and explicitly verified switching the /proc/cpuinfo "tsc" flag (as well as the userland access to the TSC) off when I wrote the code to handle the "notsc" option. Has it changed since then? I recall you modified the code a bit -- I looked at the changes then but I was pretty confident the semantics was preserved. There is no possibility to have TSC and non-TSC chips mixed in a single SMP system (due to existing hardware, even though it's possible in theory), so there is no problem with such an assymetry. Either all chips have the "tsc" flag in /proc/cpuinfo on or off. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why is double_fault serviced by a trap gate?
On Thu, Dec 07, 2000 at 04:04:21PM +, [EMAIL PROTECTED] wrote: Why is double_fault serviced by a trap gate? The problem with this is that any double-fault caused by a stack-fault, which is the usual reason, becomes a triple-fault. And a triple-fault results in a processor reset or shutdown making the fault damn near impossible to get any information on. Oughtn't the double-fault exception handler be serviced by a task gate? And similarly the NMI handler in case the NMI is on the current stack page frame? Sounds like a good idea, when you can afford a few K for a special NMI/double fault stack. On x86-64 it is planned to do that. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: [patch-2.4.0-test12-pre6] truncate(2) permissions
On Thu, Dec 07, 2000 at 10:24:31AM -0500, Alexander Viro wrote: Al, currently walking through the /usr/share/man/man2 and swearing silently... Swearing? At the POSIX decisions or at the man page quality? In the latter case, additions and corrections are very welcome. Make sure that you have 1.31 installed. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
alpha pci fixes (test12-pre7)
This should fix at least some of the boot problems reported recently.
- boot failure on Miata with 1Gb of memory, fixed by Jay Estabrook.
Address written to the Translated Base Registers of CIA/Pyxis
must be shifted by 2.
- fix oops on DP264 caused by Cypress quirk. We cannot call
pci_claim_resource() from the quirk code, otherwise on multi-hose
machines hose resources would appear to be a sibling, not parent for
the resource we want to claim - pcibios_fixup_bus() is called _after_
quirks fixup, thus pci_claim_resource() will always fail.
Fortunately, another quite simple fix is possible - just disable
resources for standard IDE ports, and generic IDE code will assume
legacy addresses.
- off by one check in pci_dma_supported().
- proper calculation of the address space size for 64-bit PCI cards.
- start resource allocation on the root bus from PCIBIOS_MIN_[IO,MEM],
not from 0. Otherwise if there is a bridge on the root bus, but no I/O
or memory, the bridge's bases would be set too low. This doesn't matter
in the I/O case since devices behind the bridge are allocated properly
anyway, but could be harmful for memory case - the bridge will block
transfers to the ISA sg window from secondary bus.
- sanity check in pci_dma_supported() for bogus regions.
Ivan.
diff -urp 2.4.0t12p7/arch/alpha/kernel/core_cia.c linux/arch/alpha/kernel/core_cia.c
--- 2.4.0t12p7/arch/alpha/kernel/core_cia.c Wed Dec 6 15:00:54 2000
+++ linux/arch/alpha/kernel/core_cia.c Thu Dec 7 13:18:33 2000
@@ -700,11 +700,11 @@ do_init_arch(int is_pyxis)
*(vip)CIA_IOC_PCI_W1_BASE = 0x4000 | 1;
*(vip)CIA_IOC_PCI_W1_MASK = (0x4000 - 1) 0xfff0;
- *(vip)CIA_IOC_PCI_T1_BASE = 0;
+ *(vip)CIA_IOC_PCI_T1_BASE = 0 2;
*(vip)CIA_IOC_PCI_W2_BASE = 0x8000 | 1;
*(vip)CIA_IOC_PCI_W2_MASK = (0x4000 - 1) 0xfff0;
- *(vip)CIA_IOC_PCI_T2_BASE = 0x4000;
+ *(vip)CIA_IOC_PCI_T2_BASE = 0x4000 2;
*(vip)CIA_IOC_PCI_W3_BASE = 0;
}
diff -urp 2.4.0t12p7/arch/alpha/kernel/pci.c linux/arch/alpha/kernel/pci.c
--- 2.4.0t12p7/arch/alpha/kernel/pci.c Wed Dec 6 15:00:54 2000
+++ linux/arch/alpha/kernel/pci.c Thu Dec 7 13:16:44 2000
@@ -90,10 +90,8 @@ quirk_cypress_ide_ports(struct pci_dev *
{
if (dev-class 8 != PCI_CLASS_STORAGE_IDE)
return;
- dev-resource[1].start |= 2;
- dev-resource[1].end = dev-resource[1].start;
- pci_claim_resource(dev, 0);
- pci_claim_resource(dev, 1);
+ dev-resource[0].flags = 0;
+ dev-resource[1].flags = 0;
}
static void __init
diff -urp 2.4.0t12p7/arch/alpha/kernel/pci_iommu.c linux/arch/alpha/kernel/pci_iommu.c
--- 2.4.0t12p7/arch/alpha/kernel/pci_iommu.cSat Sep 23 01:07:43 2000
+++ linux/arch/alpha/kernel/pci_iommu.c Thu Dec 7 13:17:36 2000
@@ -613,10 +613,10 @@ pci_dma_supported(struct pci_dev *pdev,
/* Check that we have a scatter-gather arena that fits. */
hose = pdev ? pdev-sysdata : pci_isa_hose;
arena = hose-sg_isa;
- if (arena arena-dma_base + arena-size = mask)
+ if (arena arena-dma_base + arena-size - 1 = mask)
return 1;
arena = hose-sg_pci;
- if (arena arena-dma_base + arena-size = mask)
+ if (arena arena-dma_base + arena-size - 1 = mask)
return 1;
return 0;
diff -urp 2.4.0t12p7/drivers/pci/pci.c linux/drivers/pci/pci.c
--- 2.4.0t12p7/drivers/pci/pci.cWed Dec 6 15:00:57 2000
+++ linux/drivers/pci/pci.c Thu Dec 7 14:46:49 2000
@@ -575,8 +575,9 @@ static void pci_read_bases(struct pci_de
pci_write_config_dword(dev, reg+4, ~0);
pci_read_config_dword(dev, reg+4, sz);
pci_write_config_dword(dev, reg+4, l);
- if (sz)
- res-end = res-start + (((unsigned long) ~sz) 32);
+ if (~sz)
+ res-end = res-start + 0x +
+ (((unsigned long) ~sz) 32);
#else
if (l) {
printk(KERN_ERR "PCI: Unable to handle 64-bit address
for device %s\n", dev-slot_name);
diff -urp 2.4.0t12p7/drivers/pci/setup-bus.c linux/drivers/pci/setup-bus.c
--- 2.4.0t12p7/drivers/pci/setup-bus.c Wed Dec 6 15:00:57 2000
+++ linux/drivers/pci/setup-bus.c Thu Dec 7 13:21:24 2000
@@ -205,7 +205,7 @@ pbus_assign_resources(struct pci_bus *bu
}
}
-void __init
+void __init
pci_assign_unassigned_resources(void)
{
struct pbus_set_ranges_data ranges;
@@ -215,8 +215,8 @@ pci_assign_unassigned_resources(void)
for(ln=pci_root_buses.next; ln != pci_root_buses; ln=ln-next) {
struct pci_bus *b = pci_bus_b(ln);
- ranges.io_start = b-resource[0]-start;
- ranges.mem_start = b-resource[1]-start;
+
java (and possibly other threaded apps) hanging in rt_sigsuspend
Hi Ulrich,
I saw your remarks on the kernel mailing list wrt. 'threaded processes get
stuck in rt_sigsuspend/fillonedir/exit_notify' dd. 2911-12, and thought you
might be interested in the fact that something quite like this also happens on
2.4.0-test11 with glibc-2.2 (release), BUT NOT ALWAYS...
I can reliably hang java (Blackdown port jdk1.3, FCS) using the -Xmx parameter
(which specifies a maximum heap size), the weird thing is that it does NOT hang
which this parameter is either not specified OR specified but larger than a
certain value. When it hangs, it always is stuck in a rt_sigsuspend call just
after a clone() call. An example:
[frank@behemoth frank]$ java
(java starts and spits out some info, then exits as it should)
[frank@behemoth frank]$ java -Xmx32m
(java ALWAYS gets stuck:
pipe([6, 7])= 0
clone() = 14732
[pid 14679] write(7, "\0\0\0\0\5\0\0\0~\266\2@ $T@\0 T@\0
T@\300\265\2@\0\0\0"..., 148) = 148
[pid 14679] rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
[pid 14679] write(7,
"`S\3@\0\0\0\0\20\321\377\277pD\37@\30\5\10\0\0\0\200\0"..., 148) = 148
[pid 14679] rt_sigprocmask(SIG_SETMASK, NULL, [RT_0], 8) = 0
[pid 14679] rt_sigsuspend([]
)
[frank@behemoth frank]$ java -Xmx64m
(java runs, but it gets stuck if this command is repeated a few times in quick
succession.)
[frank@behemoth frank]$ java -Xmx80m
(java runs, no matter how often the command is repeated)
Some data on the test system:
[uname -a]
Linux behemoth.localnet 2.4.0-test11 #1 SMP Wed Nov 22 22:10:52 CET 2000 i686 unknown
[/lib/libc-2.2.so]
GNU C Library stable release version 2.2, by Roland McGrath et al.
Copyright (C) 1992,93,94,95,96,97,98,99,2000 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.2 19991024 (release).
Compiled on a Linux 2.4.0-test11 system on 2000-11-23.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
The C stubs add-on version 2.1.2.
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Glibc-2.0 compatibility add-on by Cristian Gafton
linuxthreads-0.9 by Xavier Leroy
libthread_db work sponsored by Alpha Processor Inc
Report bugs using the `glibcbug' script to [EMAIL PROTECTED].
[java -version]
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.0-FCS)
Java HotSpot(TM) Client VM (build Blackdown-1.3.0-FCS, mixed mode)
Why am I sending you this report? Well, since you indicate that you are working
on a rewrite of linuxthreads, this might be of interest. Especially the weird
behaviour wrt. the maximum heap size. I do not expect nor ask you to fix the
java problems, this is purely informational...
FYI, on a linux 2.2/glibc 2.1.3 box this problem does not occur, in case you
wondered...
I cc'd this message to the blackdown team, so they know something's amiss as
well.
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ Hacker: http://www.jargon.org/html/entry/hacker.html ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: 2.4.0-test12-pre7]
I think that Linus's patch is correct and that pci/setup_res.c::pdev_enable_device() shouldn't be doing this: /* ??? Always turn on bus mastering. If the device doesn't support it, the bit will go into the bucket. */ cmd |= PCI_COMMAND_MASTER; First, the ??? makes it iffy. I would agree. There is hardware you need to enable, reset, configure and then enable the master bit on otherwise it simply starts spraying random memory addresses with bus master transfers from uninitialised hardware registers by a soft boot), then the device still knows some memory addresses to DMA into, but it shouldn't be using those. This is addressed Yep. Seen that happen with amd pcnet32 stuff when net booting. The net booter left the chip prattling into main memory, not pretty - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why is double_fault serviced by a trap gate?
On Thu, 7 Dec 2000, Andi Kleen wrote: On Thu, Dec 07, 2000 at 04:04:21PM +, [EMAIL PROTECTED] wrote: Why is double_fault serviced by a trap gate? The problem with this is that any double-fault caused by a stack-fault, which is the usual reason, becomes a triple-fault. And a triple-fault results in a processor reset or shutdown making the fault damn near impossible to get any information on. Oughtn't the double-fault exception handler be serviced by a task gate? And similarly the NMI handler in case the NMI is on the current stack page frame? Sounds like a good idea, when you can afford a few K for a special NMI/double fault stack. On x86-64 it is planned to do that. Well, at least on current ix86 processors it can't. Attempting to use a task gate appears to be a trick to cause the exception to be handled on the current stack. The hardware protection hierarchy won't let this happen. You need to have a stack that is not accessible from the mode that will be trapped. Otherwise, a user could crash the machine by setting ESP to 0 and waiting for the next context- switch or timer-tick. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Broken NR_RESERVED_FILES
On Thu, 7 Dec 2000, Tigran Aivazian wrote:
On Thu, 7 Dec 2000, Szabolcs Szakacsits wrote:
Read the whole get_empty_filp function, especially this part, note the
goto new_one below and the part you didn't include above [from
the new_one label],
if (files_stat.nr_files files_stat.max_files) {
file_list_unlock();
f = kmem_cache_alloc(filp_cachep, SLAB_KERNEL);
file_list_lock();
if (f) {
files_stat.nr_files++;
goto new_one;
}
I have read the whole function, including the above code, of course. The
new_one label has nothing to do with freelists -- it adds the file to the
anon_list, where the new arrivales from the slab cache go. The goto
new_one above is there simply to initialize the structure with sane
initial values
OK, 2.2 has
put_inuse(f);
instead of putting it to anon_list, so 2.4 seems ok.
Szaka
So, the normal user _cannot_ take a file structure from the freelist
unless it contains more than NR_RESERVED_FILE entries. Please read the
whole function and see it for yourself.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
bug: merge_segments vs. lock_vma_mappings?
Hello, since test11, the merge_segments() routine assumes that every VMA that it frees has been locked with lock_vma_mappings(). While most callers have been adapted to perform this locking, at least two, do_mlock and sys_mprotect, do *not* currently. This causes a deadlock in certain situations. What's the correct way to fix this? In mlock and mprotect, potentially many segments could be freed; do we need to call lock_vma_mappings on all of them before calling merge_segments? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand Linux for S/390 Design Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: attempt to access beyond end of device
On Thu, Dec 07, 2000 at 04:56:59PM +0100, Jan Niehusmann wrote:
ll_rw_blk.c: generic_make_request() contains the following code:
if (maxsector count || maxsector - count sector) {
bh-b_state = (1 BH_Lock) | (1 BH_Mapped);
if (blk_size[major][MINOR(bh-b_rdev)]) {
/* This may well happen - the kernel calls bread()
without checking the size of the device, e.g.,
when mounting a device. */
printk(KERN_INFO
"attempt to access beyond end of device\n");
printk(KERN_INFO "%s: rw=%d, want=%d, limit=%d\n",
kdevname(bh-b_rdev), rw,
(sector + count)1,
blk_size[major][MINOR(bh-b_rdev)]);
}
bh-b_end_io(bh, 0);
return;
}
That means that if blk_size[major][MINOR(bh-b_rdev)] == 0, the request
is canceled but no message is printed. Shouldn't there be a warning message?
Maybe that code fragment is mine. If so, then at some point
in time I decided that the answer to your question is no.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
Should be the rtl8139 driver. AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. Mike, if you have problems, search list archives: a few people (including me) reported problems under load. I've never solved them. 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be way better (but not perfect) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 64bit offsets for block devices ?
Hi, On Wed, Dec 06, 2000 at 06:50:15AM -0800, Reto Baettig wrote: Imagine we have a virtual disk which provides a 64bit (sparse) address room. Unfortunately we can not use it as a block device because in a lot of places (including buffer_head structure), we're using a long or even an int for the block number. Is there any way of getting a standardized way of doing I/O to a block device which could handle 64bit addresses for the block number? It's on the agenda for urgent fixing in 2.5 (along with block-dev-layer support for high memory on Intel, and merging in better disk profiling, and a general cleanup of the data tables in ll_rw_blk.c). Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: YMF PCI - thanks, glitches, patches (fwd)
So, it's not just a matter of changing the constants under "case SNDCTL_DSP_SPEED" in ymf_ioctl()? Actually, I hacked them to be 4000rate5 and it worked fine, but I'll drop this part of my patch if you believe it's unsafe. I'd keep it in the absence of other evidence. 8KHz is normally the low limit for AC97 codec based systems, but if the rate adaption is done in front of the codec then it may well be fine - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Alan Cox wrote: Should be the rtl8139 driver. AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. Mike, if you have problems, search list archives: a few people (including me) reported problems under load. I've never solved them. 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be way better (but not perfect) Yes, still running 2.2.17 though. The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess replaces the 538 as that is no longer listed on the Dlink site) is an rtl8139 chip. Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- James Bourne, Web Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ab.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Alan Cox wrote: Should be the rtl8139 driver. AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. Mike, if you have problems, search list archives: a few people (including me) reported problems under load. I've never solved them. 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be way better (but not perfect) Ehm, does it drive the DFE-530TX, which, I believe, it's a via-rhine? I had problems with the 530. I've been told that the 538 (rtl8139) works under the same load (NFS server on a small LAN, and a 5-ports D-Link Switch), even with the old driver. .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, James Bourne wrote: On Thu, 7 Dec 2000, Alan Cox wrote: Should be the rtl8139 driver. AFAIK, it uses the via-rhine driver. The DFE-538TX is rtl8139 based. Mike, if you have problems, search list archives: a few people (including me) reported problems under load. I've never solved them. 2.2.18pre24 has the 8139too driver that Jeff Garzik built from a mix of his own work and Don Becker's rather unreliable rtl8129.c driver. It seems to be way better (but not perfect) Yes, still running 2.2.17 though. The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess replaces the 538 as that is no longer listed on the Dlink site) is an rtl8139 chip. You mean that D-Link made a card named DFE530TX VIA based and one named DFE530TX+ rtl based? Isn't it a bit confusing? B-) Jim .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.2.18-pre24] microcode driver fixes
Hi Alan, I have looked at the state of microcode driver in 2.2.18-pre24 and found that it needs a lot of changes -- a bugfix for the case when BIOS did not update, fix to work correctly on Pentium 4 and lots of cleanups which are in 2.4 but not in 2.2. Tested under 2.2.18-pre24. Please consider applying this patch. Regards, Tigran diff -urN -X dontdiff linux/CREDITS ucode-2.2/CREDITS --- linux/CREDITS Thu Dec 7 14:27:51 2000 +++ ucode-2.2/CREDITS Thu Dec 7 14:53:22 2000 @@ -23,6 +23,12 @@ S: University of Limerick S: Ireland +N: Tigran Aivazian +E: [EMAIL PROTECTED] +W: http://www.moses.uklinux.net/patches +D: Intel IA32 microcode update driver +S: United Kingdom + N: Werner Almesberger E: [EMAIL PROTECTED] D: dosfs, LILO, some fd features, various other hacks here and there diff -urN -X dontdiff linux/Documentation/Changes ucode-2.2/Documentation/Changes --- linux/Documentation/Changes Thu Dec 7 14:27:51 2000 +++ ucode-2.2/Documentation/Changes Thu Dec 7 14:56:37 2000 @@ -517,6 +517,28 @@ Older isdn4k-utils versions don't support EXTRAVERSION into kernel version string. A upgrade to isdn4k-utils.v3.1beta7 or later is recomented. +Intel IA32 microcode + + +A driver has been added to allow updating of Intel IA32 microcode, +accessible as both a devfs regular file and as a normal (misc) +character device. If you are not using devfs you may need to: + +mkdir /dev/cpu +mknod /dev/cpu/microcode c 10 184 +chmod 0644 /dev/cpu/microcode + +as root before you can use this. You'll probably also want to +get the user-space microcode_ctl utility to use with this. + +If you have compiled the driver as a module you may need to add +the following line: + +alias char-major-10-184 microcode + +to your /etc/modules.conf file. + + Where to get the files ** diff -urN -X dontdiff linux/Documentation/Configure.help ucode-2.2/Documentation/Configure.help --- linux/Documentation/Configure.help Thu Dec 7 14:27:51 2000 +++ ucode-2.2/Documentation/Configure.help Thu Dec 7 14:58:04 2000 @@ -10408,12 +10408,12 @@ it as a module. The module will be called sbc60xxwdt.o. CONFIG_MICROCODE - /dev/cpu/microcode - Intel P6 CPU microcode support + /dev/cpu/microcode - Intel IA32 CPU microcode support If you say Y here you will be able to update the microcode on - Intel processors in the P6 family, e.g. Pentium Pro, Pentium II, - Pentium III, Xeon etc. You will obviously need the actual microcode - binary data itself which is not shipped with the Linux kernel. + Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II, + Pentium III, Xeon, Pentium 4 etc. You will obviously need the actual + microcode binary data itself which is not shipped with the Linux kernel. For latest news and information on obtaining all the required ingredients for this driver, check: @@ -10422,7 +10422,9 @@ This driver is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). The module will be called microcode.o. If you want to compile it as - a module, say M here and read Documentation/modules.txt. + a module, say M here and read Documentation/modules.txt. If you use + modprobe or kmod you may also want to add the line + 'alias char-major-10-184 microcode' to your /etc/modules.conf file. /dev/cpu/*/msr - Model-specific register support CONFIG_X86_MSR diff -urN -X dontdiff linux/Documentation/ioctl-number.txt ucode-2.2/Documentation/ioctl-number.txt --- linux/Documentation/ioctl-number.txtThu Dec 7 14:27:51 2000 +++ ucode-2.2/Documentation/ioctl-number.txtThu Dec 7 14:58:51 2000 @@ -113,6 +113,8 @@ mailto:[EMAIL PROTECTED] 'z'40-7F CAN bas cardin development: mailto:[EMAIL PROTECTED] +'6'00-10 asm-i386/processor.h Intel IA32 microcode update driver + mailto:[EMAIL PROTECTED] 0x89 00-0F asm-i386/sockios.h 0x89 10-DF linux/sockios.h 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range diff -urN -X dontdiff linux/MAINTAINERS ucode-2.2/MAINTAINERS --- linux/MAINTAINERS Thu Dec 7 14:27:51 2000 +++ ucode-2.2/MAINTAINERS Thu Dec 7 14:55:03 2000 @@ -493,6 +493,13 @@ L: [EMAIL PROTECTED] S: Maintained +INTEL IA32 MICROCODE UPDATE DRIVER +P: Tigran Aivazian +M: Tigran Aivazian [EMAIL PROTECTED] +W: http://www.urbanmyth.org/microcode +L: [EMAIL PROTECTED] +S: Maintained + IP FIREWALL P: Paul Russell M: [EMAIL PROTECTED] diff -urN -X dontdiff linux/arch/i386/config.in ucode-2.2/arch/i386/config.in --- linux/arch/i386/config.in Thu Dec 7 14:27:52 2000 +++ ucode-2.2/arch/i386/config.in Thu Dec 7 14:59:17 2000 @@ -33,7 +33,7 @@ define_bool CONFIG_X86_GOOD_APIC y fi -tristate '/dev/cpu/microcode - Intel P6 CPU microcode support'
[whitevampire@MINDLESS.COM: Naptha - New DoS]
I'm just forwarding it. I know nothing about it. I don't know how it works. I don't know how to protect agains it. I don't know what is a Kernel. I don't know what is Linux. I don't know what is e-mail. Who am I ? Where am I ? What are all those green dots in the sky ? A :-) Anyway, I talked to Riel before sending this bug here, and he acknoledged that it's really something new: riel hu riel indeed, this is a new one riel which hits in the tcp ESTABLISHED phase - Forwarded message from White Vampire [EMAIL PROTECTED] - Date: Wed, 6 Dec 2000 23:34:39 -0500 From: White Vampire [EMAIL PROTECTED] Subject: Naptha - New DoS Greetings, [ Misc Info ] I find it rather odd that this has yet to be mentioned on Bugtraq. I know of more than one person besides myself who has experienced some problems with this DoS since this advisory was released. I delayed mentioning it on this list because I figured someone from Razor would release it, or someone who was involved with the discovery. Various vendors are no doubt already coding like mad. I have disabled Keepalive in Apache (via 'Keepalive Off' in the configuration file) and changed the kernel timeouts, as recommended by the advisory. This will help some, but not enough. I hope to see complete fixes available soon, perhaps this will help kick-start it. Limiting public access to TCP daemons is also a way to help prevent attacks. [ Quick Summary ] Basically, it will leave a TCP connection on the target machine in a "certain state." The method discovered will exhaust resources on the target machine, whereas the originating machine will not be affected that greatly. Before such attacks were infeasible because the originating machine would also be affected. The target machine can be starved of resources to the point of failure. Some affected operating systems: * Novell's Netware 5.0 with sp1 (Will not recover) * Linux (2.2.x .. others ?) (Unknown.. can recover sometimes?) * FreeBSD 4.0-REL (Can recover in short period) * Possibly others.. it is a rather widespread problem. Unaffected operating systems: * OpenBSD seems to be unaffected * Windows 2000 seems to be unaffected For more information on NAPTHA visit: http://razor.bindview.com/publish/advisories/adv_NAPTHA.html [ Credit and Disclaimer ] An advisory was released by Razor on November 30th. I had not involvement with the discovery or release of this advisory. This e-Mail is simply a summary to help system administrators and other individuals who are interested or are experiencing problems learn about the attack. I shared my experiences and summarized some information from the advisory. I am just sharing the information. Good luck to the vendors, and good luck to the rest of the world. I sure have not had a fun time resulting these attacks. Regards, -- __ __ / \/ \ \ / / White Vampire\Rem \ \/\/ /\ Y / http://www.gammagear.com/ (Gear for the BOFH) \/ \ / http://www.webfringe.com/ \__/\ /\___/http://www.gammaforce.org/ \/ "Silly hacker, root is for administrators." - End forwarded message - -- Rodrigo Barbosa (morcego) - [EMAIL PROTECTED] Conectiva RD Team - http://distro.conectiva.com.br "Quis custodiet custodes?" - http://www.conectiva.com PGP signature
Re: D-LINK DFE-530-TX
On Thu, 7 Dec 2000, Marco Colombo wrote: On Thu, 7 Dec 2000, James Bourne wrote: The DFE-530TX is the viacom chipset, but the DFE530TX+ (Which I guess replaces the 538 as that is no longer listed on the Dlink site) is an rtl8139 chip. You mean that D-Link made a card named DFE530TX VIA based and one named DFE530TX+ rtl based? Isn't it a bit confusing? B-) Ya, 530TX is a 10/100 nic Davicom chipset (sorry, not viacom *slap*) http://www.dlink.com/products/adapters/dfe530tx/ 530TX+ is 10/100 with WOL and rtl8139 chipset http://www.dlink.com/products/adapters/dfe530txplus/ Jim Jim .TM. -- James Bourne, Web Systems Administrator Mount Royal College, Calgary, AB, CA www.mtroyal.ab.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Microsecond accuracy
Kotsovinos Vangelis wrote: Is there any way to measure (with microsecond accuracy) the time of a program execution (without using Machine Specific Registers) ? I've already tried getrusage(), times() and clock() but they all have 10 millisecond accuracy, even though they claim to have microsecond acuracy. The only thing that seems to work is to use one of the tools that measure performanc through accessing the machine specific registers. They give you the ability to measure the clock cycles used, but their accuracy is also very low from what I have seen up to now. Can you not just use something like gettimeofday()? Do two consecutive calls to find the execution time of the instruction itself, and then do two calls on either side of the program execution. Subtract the instruction execution time from the delta, and that should give a pretty good idea of execution time. On a 400Mhz G4, getttimeofday() consistantly takes 2 microseconds to run. -- Chris Friesen| MailStop: 043/33/F10 Nortel Networks | work: (613) 765-0557 3500 Carling Avenue | fax: (613) 765-2986 Nepean, ON K2H 8E9 Canada| email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [whitevampire@MINDLESS.COM: Naptha - New DoS]
Unaffected operating systems: * OpenBSD seems to be unaffected * Windows 2000 seems to be unaffected Someone isnt trying hard enough ;) Linux 2.4 is designed to handle some of these issues, but you need to address aspects of this in applications, protocols and elsewhere. Its basically no different to the synbomb except the resource usage is trickier to control - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: attempt to access beyond end of device
On Thu, Dec 07, 2000 at 05:34:28PM +0100, Andries Brouwer wrote: On Thu, Dec 07, 2000 at 04:56:59PM +0100, Jan Niehusmann wrote: That means that if blk_size[major][MINOR(bh-b_rdev)] == 0, the request is canceled but no message is printed. Shouldn't there be a warning message? Maybe that code fragment is mine. If so, then at some point in time I decided that the answer to your question is no. As a potential real-world case (but possibly unrelated), I had an interesting situation crop-up while I was playing with the loopback filesystems. If you just use the program-tools, you end up with a situation like: losetup blah [close all] dd blah [close all] losetup -d [blah] In my case, I was making a standalone program that did it all in one program and I messed up in the ordering of the close() and the LOOP_CLR_FD. I'm pretty sure that (with my small 10K test dataset) the I/O between the loopback device and the looped file was never hitting the disk. If I LOOP_CLR_FD before I closed, I ended up with bad data in the looped file and kernel errors syslogged: kernel: attempt to access beyond end of device kernel: 07:00: rw=1, want=1, limit=0 kernel: dev 07:00 blksize=0 blocknr=0 sector=0 size=1024 count=1 I tended to get 10 of those, one for each of the 10 1K blocks in my test dataset. Doing the close() then the LOOP_CLR_FD got rid of the errors. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: lost need_resched flag re-introduced?]
Hello! A while back I reported the lost need_resched flag bug ( it happens if need_resched is set right before switch_to() is called). Later on a one-line fix is added to __schedule_tail(). current-need_resched |= prev-need_resched; I looked at the latest kernel and found this one is gone. Is the lost need_resched problem taken care of in some other way? Or is it re-introduced? It is removed not only because it was wrong (which you have found too), but because it was useless even if copied correctly. current-need_resched is not changed in interrupt context outside runqueue lock except for scheduler timer, where copying results in nothing but spurious reschedule. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why is double_fault serviced by a trap gate?
On Thu, 7 Dec 2000, Andi Kleen wrote: Why is double_fault serviced by a trap gate? The problem with this is that any double-fault caused by a stack-fault, which is the usual reason, becomes a triple-fault. And a triple-fault results in a processor reset or shutdown making the fault damn near impossible to get any information on. Oughtn't the double-fault exception handler be serviced by a task gate? And similarly the NMI handler in case the NMI is on the current stack page frame? Sounds like a good idea, when you can afford a few K for a special NMI/double fault stack. On x86-64 it is planned to do that. A task gate is an absolute must for the double fault if we want to have a working handler. Intel warns the CPU state can be inconsistent when a double fault happens and for example I've seen cases where the saved CS and EIP were not matching each other (tests were not conducted under Linux). Also SS:ESP might be unusable leading to a triple fault. The NMI should be left alone, though, I think as we want it to be fast for the NMI watchdog. Task gates are not necessarily fast (depending on how you define "fast"). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
40Gig IDE disk wrapping around at 32Gig?
During an install of RedHat 6.1 onto a Dell Dimension L600cx, I partitioned the internal 40gig disk to include 4 partitions. I initially let the disk druid do it, but it rendered the partition table unreadable. So I used fdisk and partitioned it with primary partitions like so: (sectors = 255, heads = 63) /dev/hda1 1 -- 17 (136521 blocks) /dev/hda2 18 -- 50(265072 blocks) /dev/hda3 51 -- 3967 (31463302 blocks) /dev/hda4 3968 -- 4865(7213185 blocks) Problem is, any attempt to mkfs on /dev/hda4 seems to trash the filesystems on hda1, hda2 and hda3. It makes an ugly mess. RedHat 6.1 installs a 2.2.12 kernel, with patches. I'm ignoring /dev/hda4 for now and I've installed 2.2.17 from source. It seems reliable as long as I ignore /dev/hda4. I haven't tried it w/ 2.2.17 installed. Am I running into some limit here? Are there any known issues with Linux 2.2.12 or fdisk (or mkfs.ext2) that might relate to this? -- Steve Williams"The woods are lovely, dark and deep. [EMAIL PROTECTED] But I have promises to keep, [EMAIL PROTECTED]and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
New CD-R high capacity drive specs are coming. (fwd)
Hi, See the article below. I just read that the specs are out for three different types of CD-R drives in terms of disk capacity and speeds from Constellation 3D,and it is heading towards manufacturing. It's great for movies and coporate archiving, but was degraded for the consumer market -- Nothing above 5Gb/side for the consumer whereas for the coporate it's 200Gb/side. I don't think it will compete for the PC market unless the disk capacities are upped! Probably purposely degraded so that you can't copy a HDTV DVD to your PC CD-R disk. Here is the a href="http://biz.yahoo.com/bw/001207/ny_constel.html"link /a - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre7
On Thu, 7 Dec 2000, Russell King wrote: Is it intentional that pci_assign_unassigned_resources should: 1. enable all devices? 2. enable bus master on all devices? Probably intentional, but probably for all the wrong reasons. The device enabling is still required for all drivers that aren't PCI aware of PCI PnP issues. And remember - that used to be pretty much every single Linux driver out there. So a traditional Linux system pretty much required that all the devices came up fully enabled, because most drivers wouldn't know to enable them (as shown by the UHCI bug). These days, we should probably remove all the logic to enable everything in pci_assign_unassigned_resources(), because these days pretty much all PCI drivers are supposed to know about enabling the device (otherwise they wouldn't work in a PC PnP environment anyway). The only special case to this rule is "legacy devices" - things like serial ports in legacy regions, VGA consoles etc, where a driver can use them without even being aware of the fact that the hardware may be PCI. Those devices tend to need setup even just for booting, though, so they tend to be enabled rather early for other reasons anyway. So I would probably vote for getting rid of the device enables in pci_assign_unassigned_resources() (for all the reasons already mentioned by others - scribbling over memory due to not being quiescent etc). But it's not worth breaking now. 2.5.x material. Most PCI drivers may already do the right thing, but I bet that the USB driver wasn't the only one who forgot.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test11 and sysklogd-1.3-31
"KO" == Keith Owens [EMAIL PROTECTED] writes:
KO I would prefer to see the oops decoding completely removed from
KO klogd. The only justification for klogd converting the oops is
KO to save users from running ksymoops by hand. I would not mind
KO klogd capturing the oops text, forking to run ksymoops then
KO logging the ksymoops output. Just as along as the original text
KO was left alone and the ksymoops output was obviously
KO distinguished from real kernel output.
Since nobody else has weighed in on this issue, I quickly did the
necessary to effect Keith's suggestion. What follows is a patch to
sysklogd-1.3-31 (which after applying, ksym_mod.c can be removed):
# This is a BitKeeper generated patch for the following project:
# Project Name: Trans-lab fsimage sub-gate
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.60- 1.62
# src/sysklogd-1.3-31/ksym.c 1.1 - 1.2
# src/sysklogd-1.3-31/klogd.c 1.1 - 1.2
# src/sysklogd-1.3-31/ksyms.h 1.1 - 1.2
# src/sysklogd-1.3-31/Makefile1.1 - 1.2
#
# The following is the BitKeeper ChangeSet Log
#
# 00/12/07 [EMAIL PROTECTED] 1.61
# Remove ksym_mod.c to fix sysklogd build
#
# 00/12/07 [EMAIL PROTECTED] 1.62
# Remove a remaining prototype associated with the now deleted ksym_mod.c
#
#
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
--- a/src/sysklogd-1.3-31/Makefile Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/Makefile Thu Dec 7 11:53:56 2000
@@ -63,9 +63,8 @@
syslogd: syslogd.o pidfile.o
${CC} ${LDFLAGS} -o syslogd syslogd.o pidfile.o ${LIBS}
-klogd: klogd.o syslog.o pidfile.o ksym.o ksym_mod.o
- ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o \
- ksym_mod.o ${LIBS}
+klogd: klogd.o syslog.o pidfile.o ksym.o
+ ${CC} ${LDFLAGS} -o klogd klogd.o syslog.o pidfile.o ksym.o ${LIBS}
syslog_tst: syslog_tst.o
${CC} ${LDFLAGS} -o syslog_tst syslog_tst.o
diff -Nru a/src/sysklogd-1.3-31/klogd.c b/src/sysklogd-1.3-31/klogd.c
--- a/src/sysklogd-1.3-31/klogd.c Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/klogd.c Thu Dec 7 11:53:56 2000
@@ -415,7 +415,6 @@
if (symbol_lookup) {
if ( reload_symbols 1 )
InitKsyms(symfile);
- InitMsyms();
}
reload_symbols = change_state = 0;
return;
@@ -1059,7 +1058,6 @@
{
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
if ( (logsrc = GetKernelLogSrc()) == kernel )
LogKernelLine();
@@ -1075,7 +1073,6 @@
logsrc = GetKernelLogSrc();
if (symbol_lookup) {
InitKsyms(symfile);
- InitMsyms();
}
/* The main loop. */
diff -Nru a/src/sysklogd-1.3-31/ksym.c b/src/sysklogd-1.3-31/ksym.c
--- a/src/sysklogd-1.3-31/ksym.cThu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/ksym.cThu Dec 7 11:53:56 2000
@@ -656,9 +656,6 @@
last = sym_array[lp].name;
}
- if ( (last = LookupModuleSymbol(value, sym)) != (char *) 0 )
- return(last);
-
return((char *) 0);
}
@@ -749,7 +746,7 @@
* open for patches.
*/
if ( i_am_paranoid
-(strstr(line, "Oops:") != (char *) 0) !InitMsyms() )
+(strstr(line, "Oops:") != (char *) 0) )
Syslog(LOG_WARNING, "Cannot load kernel module symbols.\n");
diff -Nru a/src/sysklogd-1.3-31/ksyms.h b/src/sysklogd-1.3-31/ksyms.h
--- a/src/sysklogd-1.3-31/ksyms.h Thu Dec 7 11:53:56 2000
+++ b/src/sysklogd-1.3-31/ksyms.h Thu Dec 7 11:53:56 2000
@@ -32,4 +32,3 @@
/* Function prototypes. */
extern char * LookupSymbol(unsigned long, struct symbol *);
-extern char * LookupModuleSymbol(unsigned long int, struct symbol *);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9 Root no longer permitted to format floppies?
Script started on Thu Dec 7 11:44:01 2000 # fdformat /dev/fd0h1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... ioctl(FDFMTBEG): Operation not permitted # exit exit Script done on Thu Dec 7 11:44:42 2000 Who do you have to be in order to format floppy drives? Or have all the ioctl numbers been changed since 2.2.18 ? write(1, "Double-sided, 80 tracks, 18 sec/"..., 63) = 63 write(1, "Formatting ... ", 15) = 15 ioctl(3, 0x247, 0) = -1 EPERM (Operation not permitted) brk(0) = 0x804af98 brk(0x804afe8) = 0x804afe8 brk(0x804b000) = 0x804b000 brk(0x804c000) = 0x804c000 It looks like they should still be okay? fd.h:#define FDFMTBEG _IO(2,0x47) fd.h:#defineFDFMTTRK _IOW(2,0x48, struct format_descr) fd.h:#define FDFMTEND _IO(2,0x49) Maybe a broken MACRO? Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 Root no longer permitted to format floppies?
there was an issue with floppy ioctls and permission checks in block device -open routine recently. Just use test12-pre7 or other sufficiently recent kernel and it will work. If you _do_ want to know what's going on -- look for the thread where I reported that floppies can't me mounted readonly, then AV proposed the fix, then it turned out that Alain Knaff forgot to put his name in the MAINTAINERS file so we didn't tell him about the fix and it apparently broke some userspace tools. Later on, it was fixed in a way that makes everyone happy. Regards, Tigran On Thu, 7 Dec 2000, Richard B. Johnson wrote: Script started on Thu Dec 7 11:44:01 2000 # fdformat /dev/fd0h1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... ioctl(FDFMTBEG): Operation not permitted # exit exit Script done on Thu Dec 7 11:44:42 2000 Who do you have to be in order to format floppy drives? Or have all the ioctl numbers been changed since 2.2.18 ? write(1, "Double-sided, 80 tracks, 18 sec/"..., 63) = 63 write(1, "Formatting ... ", 15) = 15 ioctl(3, 0x247, 0) = -1 EPERM (Operation not permitted) brk(0) = 0x804af98 brk(0x804afe8) = 0x804afe8 brk(0x804b000) = 0x804b000 brk(0x804c000) = 0x804c000 It looks like they should still be okay? fd.h:#define FDFMTBEG _IO(2,0x47) fd.h:#define FDFMTTRK _IOW(2,0x48, struct format_descr) fd.h:#define FDFMTEND _IO(2,0x49) Maybe a broken MACRO? Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why is double_fault serviced by a trap gate?
On Thu, Dec 07, 2000 at 05:55:07PM +0100, Maciej W. Rozycki wrote: The NMI should be left alone, though, I think as we want it to be fast for the NMI watchdog. Task gates are not necessarily fast (depending on how you define "fast"). How often does the NMI watchdog handler run ? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New CD-R high capacity drive specs are coming. (fwd)
Why bother, Calimetrics has a native driver solution that does a modulation on the beam power of the laser that will triple or quadruple the current media densities with out getting new media or new drives. Just so you know that all of these new drive specs that claim to be coming, I have more than likely seen or was part of, this one did not evern register as a point of interest. I call this stuff the ONION CD, becasue the energy require to burn a 10 layer media, regardless that you use a dye laser, will rip appart. As long as they stay in the WORM mode it may be safe, but if they attemp CDRW then it will die. Cheers, Andre Hedrick CTO Timpanogas Research Group EVP Linux Development, TRG Linux ATA Development On Thu, 7 Dec 2000, M Sweger wrote: Hi, See the article below. I just read that the specs are out for three different types of CD-R drives in terms of disk capacity and speeds from Constellation 3D,and it is heading towards manufacturing. It's great for movies and coporate archiving, but was degraded for the consumer market -- Nothing above 5Gb/side for the consumer whereas for the coporate it's 200Gb/side. I don't think it will compete for the PC market unless the disk capacities are upped! Probably purposely degraded so that you can't copy a HDTV DVD to your PC CD-R disk. Here is the a href="http://biz.yahoo.com/bw/001207/ny_constel.html"link /a - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why is double_fault serviced by a trap gate?
On Thu, 7 Dec 2000, Petr Vandrovec wrote: No. If interrupt uses task gate, task switch happens. Nothing is stored in context of old process except registers into TSS. There is only one (bad) problem. If you want to get it 100% proof (it is not needed for double fault, but it is definitely needed for NMI, as NMI is very often on SMP ia32), each CPU's IRQ vector must point to different task, otherwise you can get TSS in use during doublefault, leading to triplefault again... Well, I expect wasting a descriptor and a page of memory for the purpose of a TSS is not a big problem. Yes. Currently if any ESP related problem happens in kernel, machine silently reboots without any message. With task gate (as Jeff Merkey proposed You might handle the stack fault with a task gate, actually, but I'm not sure it's worth the hassle. Handling just the double fault should be sufficient. some months ago, btw), you can even suspend offending task and recover from it... I think that also bluesmoke should use task gate, but I did not read documentation on this yet. Yep. An MCE is an abort like a double-fault, so the CPU state might be corrupted (by definition -- I have no idea whether it really happens). -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Out of socket memory? (2.4.0-test11)
Hello! What am I doing wrong? You change parameters without investigating why failure happened. This approach cannot succeed, of course. problem? Is there any way I can get runtime information from the kernel on things like amount of socket memory used and amount available? cat /proc/net/sockstat cat /proc/net/netstat cat /proc/net/snmp cat /proc/slabinfo cat /proc/net/tcp Next time when you will see these messages, do this, pack the result and send to me pointopoint. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
bug in scsi.c
hello, I have found a problem in scsi.c which in present in the 2.2 and 2.4 series. the scsi error handler thread is created with: kernel_thread((int (*)(void *)) scsi_error_handler, (void *) shpnt, 0); This will lead to problems, when you have to umount the filesystem on which the scsi-hostapter module is located. To solve to problem I would propose to change this to: kernel_thread((int (*)(void *)) scsi_error_handler, (void *) shpnt, CLONE_FILES); Bye, -- Andreas Klein [EMAIL PROTECTED] root / webmaster @cip.physik.uni-wuerzburg.de root / webmaster @www.physik.uni-wuerzburg.de _ | | | Long live our gracious AMIGA! | |___| - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 40Gig IDE disk wrapping around at 32Gig?
[EMAIL PROTECTED] said: My understanding is that the part you're accessing, above 33.6 gig, wraps around the int or whatever they use(i'm not a programmer, and i'm not going to think about what it'd actually be grin) 2.2.17 solves the problem. The 2.2.12 kernel definitely goes berserk when faced with blocks way up there. With 2.2.17, the whole disk works fine. Thanks for the fast response. -- Steve Williams"The woods are lovely, dark and deep. [EMAIL PROTECTED] But I have promises to keep, [EMAIL PROTECTED]and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kernel oops: test12-pre7, xmms, emu10k
Greetings,
2.4.0-test12-preXX has been pretty stable here on
a K6/2-450 running ipchains and various net services
in addition to workstation use.
I went to bed last night while others were listening to
xmms on my workstation while working in the room.
This morning I found that xmms was frozen, and there
were several oopsen in the logs.
After restarting X, everything is functional, and xmms
is working again -
I dimly perceive that xmms and the emu10k sound
driver seem to be involved, perhaps someone more
astute can see something more definite?
Here are the decoded oops:
ksymoops 2.3.4 on i586 2.4.0-test12-pre7. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test12-pre7/ (default)
-m /boot/System.map (specified)
Unable to handle kernel paging request at virtual address ec4b6b63
c013c668
*pde =
Oops:
CPU:0
EIP:0010:[c013c668]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 97249ff3 ebx: ecx: edx: 0001
esi: c56ba000 edi: ec4b6b57 ebp: esp: c56bbf70
ds: 0018 es: 0018 ss: 0018
Process xmms (pid: 1391, stackpage=c56bb000)
Stack: c56ba000 befffcf4 befffcf4 ffea c876ace0 ffea
befffc8c
c56bbf9c c56ba000 befffcfc 8010500c 0001 c56ba000
000188d0
1000 0003b000 d18233cc cf448900 c010a883 000b
befffd0c
Call Trace: [d18233cc] [c010a883]
Code: 8b 57 0c 39 54 24 54 7e 04 89 54 24 54 8b 6c 24 54 83 c5 1f
EIP; c013c668 sys_select+ec/5a8 =
Trace; d18233cc [emu10k1]emu10k1_audio_ioctl+0/f4
Trace; c010a883 system_call+33/40
Code; c013c668 sys_select+ec/5a8
_EIP:
Code; c013c668 sys_select+ec/5a8 =
0: 8b 57 0c movl 0xc(%edi),%edx =
Code; c013c66b sys_select+ef/5a8
3: 39 54 24 54 cmpl %edx,0x54(%esp,1)
Code; c013c66f sys_select+f3/5a8
7: 7e 04 jled _EIP+0xd c013c675
sys_select+f9/5a8
Code; c013c671 sys_select+f5/5a8
9: 89 54 24 54 movl %edx,0x54(%esp,1)
Code; c013c675 sys_select+f9/5a8
d: 8b 6c 24 54 movl 0x54(%esp,1),%ebp
Code; c013c679 sys_select+fd/5a8
11: 83 c5 1f addl $0x1f,%ebp
Unable to handle kernel paging request at virtual address ec4b6b57
c011983c
*pde =
Oops: 0002
CPU:0
EIP:0010:[c011983c]
EFLAGS: 00010282
eax: ec4b6b57 ebx: cec11640 ecx: 0206 edx: 0044
esi: c56ba000 edi: ec4b6b57 ebp: ec4b6b63 esp: c56bbe58
ds: 0018 es: 0018 ss: 0018
Process xmms (pid: 1391, stackpage=c56bb000)
Stack: cec11640 c56ba000 000b ec4b6b63 c0119e71 ec4b6b57
03b1
c0110a84 c010adae 000b c0110db2 c01e929e c56bbf3c
c56ba000
c0110a84 c023a260 c0115198 c56bbefc c56ba000
c7102000
Call Trace: [ec4b6b63] [c0119e71] [ec4b6b57] [c0110a84]
[c010adae] [c0110db2] [c01e929e]
[c0110a84] [c0115198] [d1826fdf] [c013c539] [c010a9c4]
[ec4b6b57] [c013c668] [d18233cc]
[c010a883]
Code: ff 0f 0f 94 c0 84 c0 0f 84 99 00 00 00 31 ed 31 f6 8b 57 0c
EIP; c011983c put_files_struct+8/b4 =
Trace; ec4b6b63 END_OF_CODE+1ac4c540/
Trace; c0119e71 do_exit+b9/1f4
Trace; ec4b6b57 END_OF_CODE+1ac4c534/
Trace; c0110a84 do_page_fault+0/40c
Trace; c010adae die+42/44
Trace; c0110db2 do_page_fault+32e/40c
Trace; c01e929e IRQ0x0f_interrupt+2a6e/54b8
Trace; c0110a84 do_page_fault+0/40c
Trace; c0115198 schedule+2d8/430
Trace; d1826fdf [emu10k1]copy_block+f3/100
Trace; c013c539 do_select+1f9/214
Trace; c010a9c4 error_code+34/40
Trace; ec4b6b57 END_OF_CODE+1ac4c534/
Trace; c013c668 sys_select+ec/5a8
Trace; d18233cc [emu10k1]emu10k1_audio_ioctl+0/f4
Trace; c010a883 system_call+33/40
Code; c011983c put_files_struct+8/b4
_EIP:
Code; c011983c put_files_struct+8/b4 =
0: ff 0f decl (%edi) =
Code; c011983e put_files_struct+a/b4
2: 0f 94 c0 sete %al
Code; c0119841 put_files_struct+d/b4
5: 84 c0 testb %al,%al
Code; c0119843 put_files_struct+f/b4
7: 0f 84 99 00 00 00 je a6 _EIP+0xa6 c01198e2
put_files_struct+ae/b4
Code; c0119849 put_files_struct+15/b4
d: 31 ed xorl %ebp,%ebp
Code; c011984b put_files_struct+17/b4
f: 31 f6 xorl %esi,%esi
Code; c011984d put_files_struct+19/b4
11: 8b 57 0c movl 0xc(%edi),%edx
Unable to handle kernel paging request at virtual address ec0dc836
c0119e8c
*pde =
Oops: 0002
CPU:0
EIP:0010:[c0119e8c]
EFLAGS: 00010286
eax: ebx: ec0dc836 ecx: 0206 edx:
esi: c56ba000 edi: 000b ebp: ec4b6b57 esp: c56bbd58
ds: 0018 es: 0018 ss: 0018
Process xmms (pid: 1391, stackpage=c56bb000)
Stack: 03b1 c0110a84 c010adae 000b c0110db2 c01e929e
c56bbe24
0002 c56ba000
Re: Why is double_fault serviced by a trap gate?
On Thu, 7 Dec 2000, Andi Kleen wrote: How often does the NMI watchdog handler run ? HZ times per second. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI irq routing..
On Wed, 6 Dec 2000, Linus Torvalds wrote: On Wed, 6 Dec 2000, Martin Diehl wrote: [Cardbus config space lost after APM suspend/resume] Can you remind me in a day or two if I haven't gotten back to you? I don't have any machines that need this, but I've seen ones that do, and if you're willing to test.. sure, will to do testing (and reminding ;-) Yes, this is expected for routers that we don't know about: we will still use the irq that the device claims it has, but we will obviously fail to try to route it (but it still works if the BIOS had already routed it - which is how the old code always worked anyway). btw, I'm thinking I could guess the routing from the VLSI config space, but I don't have any doc's. Would it be worth to try to add some specific get/set methods for this device? What about testers (or people who have access to the docs)? Anyway, for the suspend-resume thing, if you want to go ahead on your own without a real patch from me, the fix is along the lines of well, took me some time to follow all the paths thru cardbus/pcmcia stuff wrt suspend/resume from pm - but ended up at: - add two functions: static void yenta_save_config(pci_socket_t *socket) static void yenta_restore_config(pci_socket_t *socket) That's the crucial point, imho. The PCI layer forwards the PM events to the cardbus-driver's suspend/resume methods, which are calling pcmcia_suspend/resume_socket(). The latter in turn will call back the appropriate yenta_operations which are registered to it. So much for sure. However, there is no pcmcia_resume path forwarded to yenta since the traditional pccard_operations did not provide such a method and pcmcia simply re-initialized it's sockets. My assumption is, you haven't meant to add a do-nothing resume to all the pcmcia-stuff (including i82365, tcic) just to allow yenta to register for a resume operation which would be there for cardbus only. So my suggestion is to have cardbus_save/restore_config() exactly doing what you've said for yenta_*. - do a "yenta_save_config()" in "yenta_suspend()" and a "yenta_restore_config()" at the top of "yenta_resume()" yenta_resume() does not exist. yenta_*() replaced by cardbus_*() as explained. - test. Also test with the "pci_set_power_state(3)" in suspend enabled, because it may/should actually work with that enabled too. same point: pci_set_power_state(3) should go to cardbus_suspend(), not yenta. A first try of this ended oopsing at pm suspend somewhere below pci_pm_*(). It turned out the reason was the cardbus_suspend() (and resume too) method which was *invoked several times* in a row! The reason for this is in drivers/pci.c where bridges are touched twice: once as a device on a bus and once via -self from the bus behind. I'm not sure whether this is the intended behavior - but it definitely calls cardbus_suspend/resume() twice which breaks when forwarding to pcmcia_suspend/resume_socket(). So I've tentatively worked around using a "once" flag added to pci_socket_t. This solves the problems during suspend/resume and the cardbus' config space appears to be restored as intended - good. The bad news however is, the sockets are still broken after resume. Unfortunately there are several candidates I've spotted: - calling yenta_init() stuff at resume - is this sufficient? Probably we have to forward the pm-triggered resume from pm along pci - cardbus - pcmcia - yenta (last link currently missed, because the pcmcia layer switches from incoming resume notification to init path) - some content of the mem/io regions might need to be preserved - some TI1131 oddity wrt to CSC-INT's - requested IRQ's show up correctly in /proc/interrupts and are properly triggered and handled at card insert/eject. But after pm suspend/resume the box freezed when inserting or ejecting the cards (no response to SysRq anymore). I'll try to continue on this. Regards Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI irq routing..
On Thu, 7 Dec 2000, Martin Diehl wrote: btw, I'm thinking I could guess the routing from the VLSI config space, but I don't have any doc's. Would it be worth to try to add some specific get/set methods for this device? What about testers (or people who have access to the docs)? Please do. You might leave them commented out right now, but this is actually how most of the pirq router entries have been created: by looking at various pirq tables and matching them up with other (non-pirq) documentation and testing. Th epirq "link" value is basically completely NDA'd, and is per-chipset-specific. Nobody documents it except in their bios writers guide, if even there. yenta_resume() does not exist. yenta_*() replaced by cardbus_*() as explained. Yes. The reason for this is in drivers/pci.c where bridges are touched twice: once as a device on a bus and once via -self from the bus behind. I'm not sure whether this is the intended behavior - but it definitely calls cardbus_suspend/resume() twice which breaks when forwarding to pcmcia_suspend/resume_socket(). Not intended behaviour. The self case should be removed. So I've tentatively worked around using a "once" flag added to pci_socket_t. This solves the problems during suspend/resume and the cardbus' config space appears to be restored as intended - good. The bad news however is, the sockets are still broken after resume. Unfortunately there are several candidates I've spotted: - calling yenta_init() stuff at resume - is this sufficient? Probably we have to forward the pm-triggered resume from pm along pci - cardbus - pcmcia - yenta (last link currently missed, because the pcmcia layer switches from incoming resume notification to init path) - some content of the mem/io regions might need to be preserved - some TI1131 oddity wrt to CSC-INT's - requested IRQ's show up correctly in /proc/interrupts and are properly triggered and handled at card insert/eject. But after pm suspend/resume the box freezed when inserting or ejecting the cards (no response to SysRq anymore). Ok, definitely needs some more work. Thanks for testing - I have no hardware where this is needed. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 Root no longer permitted to format floppies?
On Thu, 7 Dec 2000, Tigran Aivazian wrote: there was an issue with floppy ioctls and permission checks in block device -open routine recently. Just use test12-pre7 or other sufficiently recent kernel and it will work. If you _do_ want to know what's going on -- look for the thread where I reported that floppies can't me mounted readonly, then AV proposed the fix, then it turned out that Alain Knaff forgot to put his name in the MAINTAINERS file so we didn't tell him about the fix and it apparently broke some userspace tools. Later on, it was fixed in a way that makes everyone happy. Regards, Tigran Okay. Looks like someone is on top of this. Cheers, Dick Johnson Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: USB-related lockup in test12-pre5
On Thu, Dec 07, 2000, David Woodhouse [EMAIL PROTECTED] wrote: Haven't tried test12-pre7 yet. Is enabling bus mastering likely to make this magically go away? I doubt it. Probably not. Enabling bus mastering is the difference between USB working at all (transfering data to the device) and not working. This happened when trying to run excel under wine. Dual Celeron with CONFIG_USB_UHCI. Could you try the alternate UHCI driver? You may need to disable the UHCI driver you have configured for the option to become visible. EIP; c0270c21 stext_lock+4e6d/8f50 = Trace; c01f488e usb_submit_urb+1e/30 Trace; ca8578be [audio]usbout_completed+7e/c0 Trace; c01ffc3e process_urb+1de/230 Trace; c01ffd49 uhci_interrupt+b9/120 It looks like you were using USB audio? Could you explain what you were doing when the oops happened? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Why is double_fault serviced by a trap gate?
On Thu, 7 Dec 2000, Andi Kleen wrote: Interesting. One of my ports references for PCs lists 0044r/w PIT counter 3 (PS/2, EISA) used as fail-safe timer. generates an NMI on time out. for user generated NMI see at 0462. Oh no, we don't use that. Even though we could, it's rare -- it exists for EISA systems only and then mostly older ones (i.e. non-PCI ones). In fact the only chipset that provides these additional NMI sources I have docs for is the i82350 one. I don't know if modern PCs still provide this counter, but if yes it could be used for a slow NMI watchdog that only runs every 30s or so. An ability to choose a NMI frequency, especially such a low one, would be desirable but it is really inexistent for most IA32 systems. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: lost need_resched flag re-introduced?]
[EMAIL PROTECTED] wrote: Hello! A while back I reported the lost need_resched flag bug ( it happens if need_resched is set right before switch_to() is called). Later on a one-line fix is added to __schedule_tail(). current-need_resched |= prev-need_resched; I looked at the latest kernel and found this one is gone. Is the lost need_resched problem taken care of in some other way? Or is it re-introduced? It is removed not only because it was wrong (which you have found too), but because it was useless even if copied correctly. current-need_resched is not changed in interrupt context outside runqueue lock except for scheduler timer, where copying results in nothing but spurious reschedule. Alexey Alexey, I think wake_up_process() is called in interrupt routine quite often and it will set need_resched flag (through reschedule_idle()). ??? I did several run time tests and confirmed the missing need_resched flag was happening. Ether some new code takes care of it. Or it is still there. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: lost need_resched flag re-introduced?]
Hello! I think wake_up_process() is called in interrupt routine quite often and it will set need_resched flag (through reschedule_idle()). ??? It sets _right_ flag cpu_curr(this_cpu)-need_resched, rather than current-need_resched. happening. Ether some new code takes care of it. Or it is still there. ? 8) Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre7
On Thu, 7 Dec 2000, Russell King wrote: Linus Torvalds writes: - me: UHCI drivers really need to enable bus mastering. But it'll already be turned on if pci_assign_unassigned_resources() is called. This calls pdev_enable_device for every single device, which turns on the bus master bit in the PCI command register. Maybe I'm stating something which is obvious to everybody, but note that pci_assign_unassigned_resources is only called from ./arch/alpha/kernel/pci.c: pci_assign_unassigned_resources(); ./arch/mips/ddb5074/pci.c: pci_assign_unassigned_resources(); ./arch/arm/kernel/bios32.c: pci_assign_unassigned_resources(); so it looks like most archs don't use it anyway. (And that's supposedly why pci_set_master helped people on x86) --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
