Re: scsi disk defect or kernel driver defect ?
"J . A . Magallon" <[EMAIL PROTECTED]> writes: > On 06.07 Nico Schottelius wrote: > > > > > > Based upon the lspci output you posted earlier, aic7880 has a single > > > SCSI bus. > > > > Oh. That could really be a problem.. I though having two different > > connectors on the board would make two different buses.. > > I must have been wrong. > > > > > So you must mean two internal connectors. Both of your devices > > > (HD and Tape) do show up on the same bus during scan. Since you have > > > connected devices to both connectors on the card, you must terminate > > > both devices. > > > > Okay, so far I understood. > > > > And, AFAIK, the controller stands in the bus between the disk and the tape, > so you should terminate both yes. > AND disable the controller internal terminator no. you should terminate high-on low-off. how can the 50 pin end terminate the extra wires of the 68 conductor wide side? > or leave it in AUTO mode. this might well work. if not, set host adapter/controller to terminate high-on low-off. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: scsi disk defect or kernel driver defect ?
J . A . Magallon [EMAIL PROTECTED] writes: On 06.07 Nico Schottelius wrote: Based upon the lspci output you posted earlier, aic7880 has a single SCSI bus. Oh. That could really be a problem.. I though having two different connectors on the board would make two different buses.. I must have been wrong. So you must mean two internal connectors. Both of your devices (HD and Tape) do show up on the same bus during scan. Since you have connected devices to both connectors on the card, you must terminate both devices. Okay, so far I understood. And, AFAIK, the controller stands in the bus between the disk and the tape, so you should terminate both yes. AND disable the controller internal terminator no. you should terminate high-on low-off. how can the 50 pin end terminate the extra wires of the 68 conductor wide side? or leave it in AUTO mode. this might well work. if not, set host adapter/controller to terminate high-on low-off. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tulip driver BROKEN in 2.4.5-pre4
Studierende der Universitaet des Saarlandes <[EMAIL PROTECTED]> writes: > Could you post the output of > > #tulip-diag -mm -aa -f > > with the broken driver? > Some code that's required for Linksys Tulip clones was moved from pnic > specific part into the generic part, perhaps that causes problems. i have a 21041 dec tulip which has failed to work with linux-2.4.5-pre[3-5] kernel drivers. (it also fails with the sourceforge devel version tulip-1.1.7) it appears that the card gets lodged in full duplex mode. however, this could just be a superficial syndrome. anyhow, here is the output of tulip-diag -mm -aa -f from the *broken* driver tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xfc00. Digital DS21140 Tulip chip registers at 0xfc00: 0x00: fff88000 03421000 03421200 fc000102 e384 fffe 0x40: fffe dff0 fffe ff59 1c09fdc0 fec8 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. No MII transceivers found! Index #2: Found a Digital DC21041 Tulip adapter at 0xf080. Digital DC21041 Tulip chip registers at 0xf080: 0x00: ffe08000 0ee4e000 0ee4e200 fc000112 fffe0200 fffe 0x40: fffe 4bf8 fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. and here is one working dump for comparison (driver 0.9.14 from sourceforge) tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xfc00. Digital DS21140 Tulip chip registers at 0xfc00: 0x00: fff88000 03421000 03421200 fc000102 e384 fffe 0x40: fffe fff597ff fffe ff59 1c09fdc0 fec8 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. No MII transceivers found! Index #2: Found a Digital DC21041 Tulip adapter at 0xf080. Digital DC21041 Tulip chip registers at 0xf080: 0x00: ffe08000 0ee4e000 0ee4e200 fc66 fffe2002 ebef 0x40: fffe 03ff fffe 01c8 ef05 ff3f 0008 Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 01c8. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tulip driver BROKEN in 2.4.5-pre4
Studierende der Universitaet des Saarlandes [EMAIL PROTECTED] writes: Could you post the output of #tulip-diag -mm -aa -f with the broken driver? Some code that's required for Linksys Tulip clones was moved from pnic specific part into the generic part, perhaps that causes problems. i have a 21041 dec tulip which has failed to work with linux-2.4.5-pre[3-5] kernel drivers. (it also fails with the sourceforge devel version tulip-1.1.7) it appears that the card gets lodged in full duplex mode. however, this could just be a superficial syndrome. anyhow, here is the output of tulip-diag -mm -aa -f from the *broken* driver tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xfc00. Digital DS21140 Tulip chip registers at 0xfc00: 0x00: fff88000 03421000 03421200 fc000102 e384 fffe 0x40: fffe dff0 fffe ff59 1c09fdc0 fec8 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. No MII transceivers found! Index #2: Found a Digital DC21041 Tulip adapter at 0xf080. Digital DC21041 Tulip chip registers at 0xf080: 0x00: ffe08000 0ee4e000 0ee4e200 fc000112 fffe0200 fffe 0x40: fffe 4bf8 fffe 50c8 ef01 0008 Port selection is full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit unit is set to store-and-forward. The NWay status register is 50c8. No MII transceivers found! Internal autonegotiation state is 'Negotiation complete'. and here is one working dump for comparison (driver 0.9.14 from sourceforge) tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xfc00. Digital DS21140 Tulip chip registers at 0xfc00: 0x00: fff88000 03421000 03421200 fc000102 e384 fffe 0x40: fffe fff597ff fffe ff59 1c09fdc0 fec8 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. No MII transceivers found! Index #2: Found a Digital DC21041 Tulip adapter at 0xf080. Digital DC21041 Tulip chip registers at 0xf080: 0x00: ffe08000 0ee4e000 0ee4e200 fc66 fffe2002 ebef 0x40: fffe 03ff fffe 01c8 ef05 ff3f 0008 Port selection is half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. The NWay status register is 01c8. No MII transceivers found! Internal autonegotiation state is 'Autonegotiation disabled'. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About rebuild 2.4.x kernel to support SMP.
<[EMAIL PROTECTED]> writes: > On Thu, 26 Apr 2001, Yiping Chen wrote: > > > So, I have two question now, > > 1. how to determine whether your kernel support SMP? > > Somebody taugh me that you can type "uname -r", but it seems not > > correct. > > No, it's correct: the Red Hat RPM is build from the kernel.spec file which > adds the smp string to the version. "uname -a" will show SMP status. euler(jk)$ uname -a Linux euler.axel.nom 2.4.4-pre5 #1 SMP Thu Apr 19 19:20:40 EDT 2001 i686 unknown this is on a redhat system, but i think it will work on any linux system. > > 2. I remember in 2.2.x, when I rebuild the kernel which support SMP, the > > compile > > argument will include -D__SMP__ , but this time, when I rebuild kernel > > 2.4.2-2 , it didn't appear. > > Why? > > Because you've made an assumption that holds no value. 2.4 kernels rely > on CONFIG_SMP instead of __SMP__. it's probably easiest to download the latest kernel (2.4.3 at the time of this writing) from ftp.XX.kernel.org (XX being your country code). then configure using "make xconfig" or "make menuconfig". choose SMP in one of the first menus. there's a kernel-howto which explains this stuff. btw there is no problem running your own kernels on a redhat system bypassing rpm. in a source tree in which you've compiled SMP and want UP or vice-versa, i think to do a "make distclean" in between switching. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About rebuild 2.4.x kernel to support SMP.
[EMAIL PROTECTED] writes: On Thu, 26 Apr 2001, Yiping Chen wrote: So, I have two question now, 1. how to determine whether your kernel support SMP? Somebody taugh me that you can type uname -r, but it seems not correct. No, it's correct: the Red Hat RPM is build from the kernel.spec file which adds the smp string to the version. uname -a will show SMP status. euler(jk)$ uname -a Linux euler.axel.nom 2.4.4-pre5 #1 SMP Thu Apr 19 19:20:40 EDT 2001 i686 unknown this is on a redhat system, but i think it will work on any linux system. 2. I remember in 2.2.x, when I rebuild the kernel which support SMP, the compile argument will include -D__SMP__ , but this time, when I rebuild kernel 2.4.2-2 , it didn't appear. Why? Because you've made an assumption that holds no value. 2.4 kernels rely on CONFIG_SMP instead of __SMP__. it's probably easiest to download the latest kernel (2.4.3 at the time of this writing) from ftp.XX.kernel.org (XX being your country code). then configure using make xconfig or make menuconfig. choose SMP in one of the first menus. there's a kernel-howto which explains this stuff. btw there is no problem running your own kernels on a redhat system bypassing rpm. in a source tree in which you've compiled SMP and want UP or vice-versa, i think to do a make distclean in between switching. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Alan Cox wrote: > > > > > Another example: all the stupid pseudo-SCSI drivers that got their own > > > major numbers, and wanted their very own names in /dev. They are BAD for > > > the user. Install-scripts etc used to be able to just test /dev/hd[a-d] > > > and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI > > > > Sorry here I have to disagree. This is _policy_ and does not belong in the > > kernel. I can call them all /dev/hdfoo or /dev/disc/blah regardless of > > major/minor encoding. If you dont mind kernel based policy then devfs > > with /dev/disc already sorts this out nicely. > > > > IMHO more procfs crud is also not the answer. procfs is already poorly > > managed with arbitary and semi-random namespace. Its a beautiful example of > > why adhoc naming is as broken as random dev_t allocations. Maybe Al Viro's > > per device file systems solve that. > > > > In some ways, they make matters worse -- now you have to effectively keep > a device list in /etc/fstab. Not exactly user friendly. > > devfs -- in the abstract -- really isn't that bad of an idea; after all, > device names really do specify an interface. Something I suggested also, > at some point, was to be able to pass strings onto character device > drivers (so that if /dev/foo is a char device, /dev/foo/bar would access > the same device with the string "bar" passed on to the device driver -- > this would help deal with "same device, different options" such as > /dev/ttyS0 versus /dev/cua0 -- having flags to open() is really ugly > since there tends to be no easy way to pass them down through multiple > layers of user-space code.) > > The problems with devfs (other than kernel memory bloat, which is pretty > much guaranteed to be much worse than the bloat a larger dev_t would > entail) is that it needs complex auxilliary mechanisms to make > "chmod /dev/foo" work as expected (the change to /dev/foo is to be > permanent, without having to edit some silly config file) the permanent storage for a PC computer is naturally the hard disk. you could always make a device partition to store persistant state. i think a few megabytes should be enough. it could be substatially less if you had good defaults and disk storage was only used to override the default. of course, using disk brings us full circle back to device nodes on filesystem. the impetus behind devfs was never (afaict) saving disk space or getting around slow disk access. people want device nodes to appear automatically and go away again when drivers are removed. i think what all this means is that between kernel and collection of the user space programs the filesystem semantics just doesn't have enough going for it in order to do all that you want with devices. it might be a mostly userspace solvable problem. a device daemon could create new devices on the fly, only they'd be ordinary filesystem devices. for example it might be better to hack ls to not show dormant devices. a cronjob could call a grim device reaper to cull nodes not used for a long time... what do other vaguely unix-like systems do? does, say, plan9 have a better way of dealing with all this? -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Larger dev_t
"H. Peter Anvin" [EMAIL PROTECTED] writes: Alan Cox wrote: Another example: all the stupid pseudo-SCSI drivers that got their own major numbers, and wanted their very own names in /dev. They are BAD for the user. Install-scripts etc used to be able to just test /dev/hd[a-d] and /dev/sd[0-x] and they'd get all the disks. Deficiencies in the SCSI Sorry here I have to disagree. This is _policy_ and does not belong in the kernel. I can call them all /dev/hdfoo or /dev/disc/blah regardless of major/minor encoding. If you dont mind kernel based policy then devfs with /dev/disc already sorts this out nicely. IMHO more procfs crud is also not the answer. procfs is already poorly managed with arbitary and semi-random namespace. Its a beautiful example of why adhoc naming is as broken as random dev_t allocations. Maybe Al Viro's per device file systems solve that. In some ways, they make matters worse -- now you have to effectively keep a device list in /etc/fstab. Not exactly user friendly. devfs -- in the abstract -- really isn't that bad of an idea; after all, device names really do specify an interface. Something I suggested also, at some point, was to be able to pass strings onto character device drivers (so that if /dev/foo is a char device, /dev/foo/bar would access the same device with the string "bar" passed on to the device driver -- this would help deal with "same device, different options" such as /dev/ttyS0 versus /dev/cua0 -- having flags to open() is really ugly since there tends to be no easy way to pass them down through multiple layers of user-space code.) The problems with devfs (other than kernel memory bloat, which is pretty much guaranteed to be much worse than the bloat a larger dev_t would entail) is that it needs complex auxilliary mechanisms to make "chmod /dev/foo" work as expected (the change to /dev/foo is to be permanent, without having to edit some silly config file) the permanent storage for a PC computer is naturally the hard disk. you could always make a device partition to store persistant state. i think a few megabytes should be enough. it could be substatially less if you had good defaults and disk storage was only used to override the default. of course, using disk brings us full circle back to device nodes on filesystem. the impetus behind devfs was never (afaict) saving disk space or getting around slow disk access. people want device nodes to appear automatically and go away again when drivers are removed. i think what all this means is that between kernel and collection of the user space programs the filesystem semantics just doesn't have enough going for it in order to do all that you want with devices. it might be a mostly userspace solvable problem. a device daemon could create new devices on the fly, only they'd be ordinary filesystem devices. for example it might be better to hack ls to not show dormant devices. a cronjob could call a grim device reaper to cull nodes not used for a long time... what do other vaguely unix-like systems do? does, say, plan9 have a better way of dealing with all this? -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ReiserFS Oops (2.4.1, deterministic, symlink related)
Ion Badulescu <[EMAIL PROTECTED]> writes: > On Fri, 2 Feb 2001, Alan Cox wrote: > > > Oh I can see why Hans wants to cut down his bug reporting load. I can also > > say from experience it wont work. If you put #error in then everyone will > > mail him and complain it doesnt build, if you put #warning in nobody will > > read it and if you dont put anything in you get the odd bug report anyway. > > > > Basically you can't win and unfortunately a shrink wrap forcing the user > > to read the README file for the kernel violates the GPL .. > > Oh, don't get me wrong, I fully understand that it's a lose-lose > situation. All I'm saying is that it was an incredibly bad idea to have > two compilers, one broken and one ok, identify themselves as the same > version. unfortunately, it's not limited to redhat and it's not limited to redhat's gcc-2.96. gcc-2.95.2 has some bugs (a certain strength reduction bug comes to mind). no new official gcc has come for over a year. many distributions have applied a patch to fix the strength reduction bug. do they all alter their version number? of those that do, do they alter it consistently? -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: ReiserFS Oops (2.4.1, deterministic, symlink related)
Ion Badulescu [EMAIL PROTECTED] writes: On Fri, 2 Feb 2001, Alan Cox wrote: Oh I can see why Hans wants to cut down his bug reporting load. I can also say from experience it wont work. If you put #error in then everyone will mail him and complain it doesnt build, if you put #warning in nobody will read it and if you dont put anything in you get the odd bug report anyway. Basically you can't win and unfortunately a shrink wrap forcing the user to read the README file for the kernel violates the GPL .. Oh, don't get me wrong, I fully understand that it's a lose-lose situation. All I'm saying is that it was an incredibly bad idea to have two compilers, one broken and one ok, identify themselves as the same version. unfortunately, it's not limited to redhat and it's not limited to redhat's gcc-2.96. gcc-2.95.2 has some bugs (a certain strength reduction bug comes to mind). no new official gcc has come for over a year. many distributions have applied a patch to fix the strength reduction bug. do they all alter their version number? of those that do, do they alter it consistently? -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: Poor SCSI drive performance on SMP machine, 2.2.16
"paradox3" <[EMAIL PROTECTED]> writes: > Here is the output from dmesg. How do I tell if it is improperly > terminated? you never gave the model of the hard drive (or if you did, i didn't see it), but you did say a 10k rpm ibm. i am going to assume it is u2w/lvd capable. no lvd hard drive has termination built in. you must use a seperate termination device at the end of the ribbon. or you can use a terminating cable. since your controller is a single-ended device, get a single-ended, wide, active terminator and plug it into the end of the ribbon. put the hard drive in the middle somewhere. see http://www.scsifaq.org/> for more information. > Thanks, Para-dox ([EMAIL PROTECTED]) > > > > > - Original Message - > From: "Michael Brown" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, January 28, 2001 11:12 PM > Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 > > > > Your problem appears to be improper SCSI termination. > > > > You need to either > > 1) make sure your SCSI drive has termination enabled > > or > > 2) move your SCSI drive to the middle connector and put a terminator on > > the last connector > > > > Check your syslog and post to l-k the part where it detects your drives. > > I'll bet the adapter is throttling back quite dramatically in the presence > > of improper termination. > > > > -- > > Michael Brown > > > > _ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > > > -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: Poor SCSI drive performance on SMP machine, 2.2.16
"paradox3" [EMAIL PROTECTED] writes: Here is the output from dmesg. How do I tell if it is improperly terminated? you never gave the model of the hard drive (or if you did, i didn't see it), but you did say a 10k rpm ibm. i am going to assume it is u2w/lvd capable. no lvd hard drive has termination built in. you must use a seperate termination device at the end of the ribbon. or you can use a terminating cable. since your controller is a single-ended device, get a single-ended, wide, active terminator and plug it into the end of the ribbon. put the hard drive in the middle somewhere. see URL:http://www.scsifaq.org/ for more information. Thanks, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Michael Brown" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 28, 2001 11:12 PM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 Your problem appears to be improper SCSI termination. You need to either 1) make sure your SCSI drive has termination enabled or 2) move your SCSI drive to the middle connector and put a terminator on the last connector Check your syslog and post to l-k the part where it detects your drives. I'll bet the adapter is throttling back quite dramatically in the presence of improper termination. -- Michael Brown _ Get your FREE download of MSN Explorer at http://explorer.msn.com -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: Poor SCSI drive performance on SMP machine, 2.2.16
"paradox3" <[EMAIL PROTECTED]> writes: > I did this: > > date > dd if=/dev/zero of=TESTFILE bs=1024 count=102400 > date > sync > date > > > and I gave the time differences from the first to the last > timestamp. hmm. i ran this on my old ppro200 with adaptec 2940uw and ibm DDRS-39130W drive. sophia(jk)$ cat foo date dd if=/dev/zero of=TESTFILE bs=1024 count=102400 date sync sync sync date i get sophia(jk)$ time bash foo Sun Jan 28 18:41:52 EST 2001 102400+0 records in 102400+0 records out Sun Jan 28 18:42:11 EST 2001 Sun Jan 28 18:42:13 EST 2001 real0m20.803s user0m0.400s sys 0m8.780s and this during a full kernel compile. i get similar decent results using my other computer with a symbios 8751sp and fujitsu and seagate drives. something must be messed up in a configuration somewhere. are you sure you are running the drive in synchronous ultra wide mode? is you termination good? > Regards, Para-dox ([EMAIL PROTECTED]) > > > > - Original Message - > From: "Bruce Harada" <[EMAIL PROTECTED]> > To: "paradox3" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, January 28, 2001 2:31 PM > Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 > > > > > > Hm. As a point of comparison, I use a similar system to yours (full SCSI, > > though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the > > same disk, in around 13 seconds. Where are you copying to the SCSI drive > > from - the same drive, an IDE disk, CDROM? If IDE, what are its > > particulars? (Check with hdparm -iI /dev/hd?) > > > > -- > > Bruce Harada > > [EMAIL PROTECTED] > > > > > > > > On Sun, 28 Jan 2001 12:44:29 -0500 > > "paradox3" <[EMAIL PROTECTED]> wrote: > > > > > > I don't get any messages relating to the drives in any syslog output. > > > > > > > > > > > Do you get messages like the ones below in /var/log/messages? > > > > > > > > sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs > > > > sym53c875-0-<0,0>: tagged command queue depth set to 7 > > > > > > > > In fact, do you get any messages in your log files that look like they > > > > might be related? > > > > > > - > > 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/ -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: Poor SCSI drive performance on SMP machine, 2.2.16
"paradox3" [EMAIL PROTECTED] writes: I did this: date dd if=/dev/zero of=TESTFILE bs=1024 count=102400 date sync date and I gave the time differences from the first to the last timestamp. hmm. i ran this on my old ppro200 with adaptec 2940uw and ibm DDRS-39130W drive. sophia(jk)$ cat foo date dd if=/dev/zero of=TESTFILE bs=1024 count=102400 date sync sync sync date i get sophia(jk)$ time bash foo Sun Jan 28 18:41:52 EST 2001 102400+0 records in 102400+0 records out Sun Jan 28 18:42:11 EST 2001 Sun Jan 28 18:42:13 EST 2001 real0m20.803s user0m0.400s sys 0m8.780s and this during a full kernel compile. i get similar decent results using my other computer with a symbios 8751sp and fujitsu and seagate drives. something must be messed up in a configuration somewhere. are you sure you are running the drive in synchronous ultra wide mode? is you termination good? Regards, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Bruce Harada" [EMAIL PROTECTED] To: "paradox3" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, January 28, 2001 2:31 PM Subject: Re: Poor SCSI drive performance on SMP machine, 2.2.16 Hm. As a point of comparison, I use a similar system to yours (full SCSI, though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the same disk, in around 13 seconds. Where are you copying to the SCSI drive from - the same drive, an IDE disk, CDROM? If IDE, what are its particulars? (Check with hdparm -iI /dev/hd?) -- Bruce Harada [EMAIL PROTECTED] On Sun, 28 Jan 2001 12:44:29 -0500 "paradox3" [EMAIL PROTECTED] wrote: I don't get any messages relating to the drives in any syslog output. Do you get messages like the ones below in /var/log/messages? sym53c875-0-0,0: QUEUE FULL! 8 busy, 7 disconnected CCBs sym53c875-0-0,0: tagged command queue depth set to 7 In fact, do you get any messages in your log files that look like they might be related? - 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/ -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Rusty Russell <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> you write: > > yes, but is it a dual machine or is it an N-way SMP with N > 2? the > > other guy with iptables/SMP problems also has a quad box. could this > > perhaps be a problem only when you have more than two processors? > > Yes, hacked my machine to think it had 4 cpus, and boom. > > There are two problems: > (1) initialization of multiple tables was wrong, and > (2) iterating through tables should not use cpu_number_map (doesn't > matter on X86 though). > > Please try attached patch. ok i'll give this a whirl success! netfilter/iptables seems to be up and working on my quad ppro box now. i am running your "quick guide to firewalling" from the howto until i get my rules straightened out. thank you very much. johan -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Rusty Russell [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] you write: yes, but is it a dual machine or is it an N-way SMP with N 2? the other guy with iptables/SMP problems also has a quad box. could this perhaps be a problem only when you have more than two processors? Yes, hacked my machine to think it had 4 cpus, and boom. There are two problems: (1) initialization of multiple tables was wrong, and (2) iterating through tables should not use cpu_number_map (doesn't matter on X86 though). Please try attached patch. ok i'll give this a whirl success! netfilter/iptables seems to be up and working on my quad ppro box now. i am running your "quick guide to firewalling" from the howto until i get my rules straightened out. thank you very much. johan -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Rusty Russell <[EMAIL PROTECTED]> writes: > In message <[EMAIL PROTECTED]> you write: > > > > I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) > > machine. I have tried both test versions of the kernel. I configured > > the kernel for single > > and multi processor. When I boot single processor, iptables will run > > fine. When I boot the machine with the multiprocessor kernel and run > > iptables, the kernel dumps several pages of hex and the final two lines > > of output are: > > > > Killing interrupt handler > > scheduling in interrupt > > My development box (running test10pre5) is SMP, and it works fine. yes, but is it a dual machine or is it an N-way SMP with N > 2? the other guy with iptables/SMP problems also has a quad box. could this perhaps be a problem only when you have more than two processors? > I > haven't updated to the latest kernel version because I like my > filesystems in one piece, and the netfilter code hasn't changed. > > What is your kernel configuration, and iptables version? Have you > patched the kernel? i tried 2.4.0-test10 (no patches) with iptables 1.1.2. this is an alr revolution quad6 (4 ppros). i posted this to the netfilter mailing list a while back. http://lists.samba.org/pipermail/netfilter/2000-November/005838.html> -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Rusty Russell [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] you write: I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) machine. I have tried both test versions of the kernel. I configured the kernel for single and multi processor. When I boot single processor, iptables will run fine. When I boot the machine with the multiprocessor kernel and run iptables, the kernel dumps several pages of hex and the final two lines of output are: Killing interrupt handler scheduling in interrupt My development box (running test10pre5) is SMP, and it works fine. yes, but is it a dual machine or is it an N-way SMP with N 2? the other guy with iptables/SMP problems also has a quad box. could this perhaps be a problem only when you have more than two processors? I haven't updated to the latest kernel version because I like my filesystems in one piece, and the netfilter code hasn't changed. What is your kernel configuration, and iptables version? Have you patched the kernel? i tried 2.4.0-test10 (no patches) with iptables 1.1.2. this is an alr revolution quad6 (4 ppros). i posted this to the netfilter mailing list a while back. URL:http://lists.samba.org/pipermail/netfilter/2000-November/005838.html -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Roger Crandell <[EMAIL PROTECTED]> writes: > I should have mentioned this is a 4 processor machine with a 64 bit > buss. perhaps the netfilter stuff isn't 4-way SMP safe. my quad ppro box seizes with iptables too. however, many people report it working with 2-way SMP boxen. has anyone gotten netfilter/iptables to work on a SMP box with more than 2 processors? i recall old 2.0.x kernels deadlocking on a 4-way until x=35 or so. maybe this is somehow similar. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Roger Crandell <[EMAIL PROTECTED]> writes: > I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) > machine. I have tried both test versions of the kernel. I configured > the kernel for single > and multi processor. When I boot single processor, iptables will run > fine. When I boot the machine with the multiprocessor kernel and run > iptables, the kernel dumps several pages of hex and the final two lines > of output are: > > Killing interrupt handler > scheduling in interrupt > > The kernel logs nothing and you must reset the machine to bring it back > up. I believe this is a kernel issue rather than an iptables > issue. > > Does anyone have experience with iptables on a multiprocessor > machine? i tried it about a month back with -test11. my quad ppro simply locked up and died when i issued "iptables -nL". i got no logs just a freeze. perhaps only my keyboard mouse and NIC died and the rest of the machine kept on running. i posted a couple of times to the netfilter mailing list but got zero response. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Roger Crandell [EMAIL PROTECTED] writes: I have 2.4.0 test 10 and test 11 installed on a multiprocessor (Intel) machine. I have tried both test versions of the kernel. I configured the kernel for single and multi processor. When I boot single processor, iptables will run fine. When I boot the machine with the multiprocessor kernel and run iptables, the kernel dumps several pages of hex and the final two lines of output are: Killing interrupt handler scheduling in interrupt The kernel logs nothing and you must reset the machine to bring it back up. I believe this is a kernel issue rather than an iptables issue. Does anyone have experience with iptables on a multiprocessor machine? i tried it about a month back with -test11. my quad ppro simply locked up and died when i issued "iptables -nL". i got no logs just a freeze. perhaps only my keyboard mouse and NIC died and the rest of the machine kept on running. i posted a couple of times to the netfilter mailing list but got zero response. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: multiprocessor kernel problem
Roger Crandell [EMAIL PROTECTED] writes: I should have mentioned this is a 4 processor machine with a 64 bit buss. perhaps the netfilter stuff isn't 4-way SMP safe. my quad ppro box seizes with iptables too. however, many people report it working with 2-way SMP boxen. has anyone gotten netfilter/iptables to work on a SMP box with more than 2 processors? i recall old 2.0.x kernels deadlocking on a 4-way until x=35 or so. maybe this is somehow similar. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: Kernel 2.2.18 and GCC versions
Harald Welte <[EMAIL PROTECTED]> writes: > On Thu, Oct 12, 2000 at 11:59:51PM +0200, J . A . Magallon wrote: > > Hi, everybody. > > > > Kernel 2.2.18-pre15 compiles fine under gcc-2.95.2. It is just plain > > 2.2.17 with Alan's patch to 18-pre15. > > > > I downloaded the gcc-2.96 rpms from rufus, and the compilation process > > there is no such thing as gcc-2.96. Try reading > > http://gcc.gnu.org/gcc-2.96.html we know. however, redhat's gcc patching does have that name. hence while it may not be "official" over at the gcc steering commitee, gcc-2.96 does, in practice and fact, exist. everyone knows what redhat gcc-2.96 means. don't be silly. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: Kernel 2.2.18 and GCC versions
Harald Welte [EMAIL PROTECTED] writes: On Thu, Oct 12, 2000 at 11:59:51PM +0200, J . A . Magallon wrote: Hi, everybody. Kernel 2.2.18-pre15 compiles fine under gcc-2.95.2. It is just plain 2.2.17 with Alan's patch to 18-pre15. I downloaded the gcc-2.96 rpms from rufus, and the compilation process there is no such thing as gcc-2.96. Try reading http://gcc.gnu.org/gcc-2.96.html we know. however, redhat's gcc patching does have that name. hence while it may not be "official" over at the gcc steering commitee, gcc-2.96 does, in practice and fact, exist. everyone knows what redhat gcc-2.96 means. don't be silly. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: AW: Linux kernel modules development in C++
Carsten Lang <[EMAIL PROTECTED]> writes: > Hi, > i don't want to start discussing the pros and cons of using C++ in kernel > development. > BUT: why do we blame people if they want to? several reasons 1) this thread keeps coming back on linux-kernel and various linux related usenet groups every couple of months or so. the people who ask are either slow learners or incapable of using dejanews. 2) someone always suggests putting in C++ but never wants to do the work to do it themselves. if they are so gung ho about the idea, they are free to fork off a variant kernel path. > It is possible to produce stable and good C++ modules (i have one for a > framegrabber device) it's also trivial to write very bad code in C++ since the compiler will try to do a lot of stuff behind the scenes. > and it is much easier to port already exsiting C++ > drivers from windows to linux. how many of these are out there? seriously, if you want to share driver code between windows and linux i see no reason not to write the whole thing in plain C in the first place. > So all i want to ask for is to give an easy way to people to > write their modules in C++. please, be my guest. no one is stopping you in this effort. > All we have to do is to change some few > lines in the kernel (the variable names "class", "public" and so on). > I'm VERY sure, that after this annoying problem is solved, we have > a C++ capsule which can be used by hardware manufacturers to > provide their Linux-drivers very fast by porting them from windows to > Linux by using a generic (C++) interface. > I don't need a very good and fast operating system, because of being > written in C, which is not supported by my hardware... > Somebody thought about that? > In my opinion we should not change the whole system to C++, > that would be very crazy (although i'm quite sure the quality of > Linux would increase), but I want to choose the language i'm > writing my device drivers in. > And if the changes are so ridiculous small, why don't we start doing > them no, why don't *you* start doing them. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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: AW: Linux kernel modules development in C++
Carsten Lang [EMAIL PROTECTED] writes: Hi, i don't want to start discussing the pros and cons of using C++ in kernel development. BUT: why do we blame people if they want to? several reasons 1) this thread keeps coming back on linux-kernel and various linux related usenet groups every couple of months or so. the people who ask are either slow learners or incapable of using dejanews. 2) someone always suggests putting in C++ but never wants to do the work to do it themselves. if they are so gung ho about the idea, they are free to fork off a variant kernel path. It is possible to produce stable and good C++ modules (i have one for a framegrabber device) it's also trivial to write very bad code in C++ since the compiler will try to do a lot of stuff behind the scenes. and it is much easier to port already exsiting C++ drivers from windows to linux. how many of these are out there? seriously, if you want to share driver code between windows and linux i see no reason not to write the whole thing in plain C in the first place. So all i want to ask for is to give an easy way to people to write their modules in C++. please, be my guest. no one is stopping you in this effort. All we have to do is to change some few lines in the kernel (the variable names "class", "public" and so on). I'm VERY sure, that after this annoying problem is solved, we have a C++ capsule which can be used by hardware manufacturers to provide their Linux-drivers very fast by porting them from windows to Linux by using a generic (C++) interface. I don't need a very good and fast operating system, because of being written in C, which is not supported by my hardware... Somebody thought about that? In my opinion we should not change the whole system to C++, that would be very crazy (although i'm quite sure the quality of Linux would increase), but I want to choose the language i'm writing my device drivers in. And if the changes are so ridiculous small, why don't we start doing them no, why don't *you* start doing them. -- J o h a n K u l l s t a m [[EMAIL PROTECTED]] Don't Fear the Penguin! - 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/
