Strange output for hw command on 5.0.7

After Installing 5.0.7 on a Dell T310 with Xeon X3550 2.66GHz 4-core CPU. I tried to run hw to identify the embedded NIC but the output of hw is unlike anything I've seen before (this hw was run after installing bnxii NIC driver): hw -v: Report about cpu for dunix.testdom.com on Fri Mar 25 00:06:23 2011 There are 4 CPUs on this system. Maximum: 10 Configured: 4 Active: 4 CPU 1 performs like a 1221Mhz Intel Pentium greater than III Processor: 1 (0xffffe) Physical CPU: 1 Logical CPU: 1 Vendor ID: GenuineIntel cpu_family: 6 cpu_id: 0x000106e5 type: 0 family: 6 model: 14 stepping: 5 brandId: 0 cpu_features: 0xbfebfbff ACPI: Yes ACPI Thermal Throttle Regs APIC: Yes APIC on Chip CLFSH: Yes Cache Line Flush Instruction CMOV: Yes Conditional Move and Compare Instructions CX8: Yes CMPXCHG8B instruction DE: Yes Debugging Extensions DS: Yes Debug Trace and EMON Store FPU: Yes FPU on chip FXSR: Yes Fast floating point save and restore HTT: Yes Hyper-Threading Technology MCA: Yes Machine Check Architecture MCE: Yes Machine Check Exception MMX: Yes MMX Technology Supported MSR: Yes RDMSR and WRMSR Support MTRR: Yes Memory Type Range Registers PAE: Yes Physical Address Extensions PAT: Yes Page Attribute Table PGE: Yes PTE Global Flag PSE: Yes Page Size Extensions PSE-36: Yes 36-bit Page Size Extensions PSN: No Processor Serial Number SEP: Yes Fast System Call SS: Yes Self-Snoop SSE: Yes Streaming SIMD Extensions SSE2: Yes Streaming SIMD Extensions 2 TM: Yes Automatic Thermal Monitor TSC: Yes Time Stamp Counter VME: Yes Virtual 8086 Mode Enhancement microdata: 2124 derived speed: 1220.69 MHz CPU supports Hyper-Threading Technology: Yes Processor Cores: 8 Logical Processors: 16 Initial APIC ID: 0x00 Physical Processor ID: 0x00 Processor Core ID: 0x00 Logical Processor ID: 0x00 Model Specific Registers 16: TSC: 0x00003f2d00ea8ba0 27: APIC_BASE: 0x00000000fee00900 BootStrap Processor: Yes APIC Global Enable: Enabled 42: EBL_CR_POWERON: 0x0000000000000000 Clock Frequency Ratio: 0 51: TEST_CTL: 0x0000000000000000 Instruction Streaming Buffers: Enabled 377: MCG_CAP: 0x0000000000001c09 Error Reporting Banks: 9 MCG_CTL MSR Present: No 1024: MC0_CTL: 0x00000000000007ff 1028: MC1_CTL: 0x0000000000000000 1032: MC2_CTL: 0x000000000000000f 1036: MC4_CTL: 0x0000000000000003 1040: MC3_CTL: 0x0000000000000003 CPU 2 performs like a 1221Mhz Intel Pentium greater than III Processor: 2 (0x00) Physical CPU: 1 Logical CPU: 3 Vendor ID: GenuineIntel cpu_family: 6 cpu_id: 0x000106e5 type: 0 family: 6 model: 14 stepping: 5 brandId: 0 .... Report about MP for dunix.testdom.com on Fri Mar 25 00:06:23 2011 There are 4 CPUs on this system. Maximum: 10 Configured: 4 Active: 4 Your system is using the `pcmp' GPI MP Vendor: 0x0010 Intel Multiprocessor Specification Vendor class: 0x2000 Intel Multiprocessor Specification MP Version: mpsw version 3 Intel MPS driver data: Floating Structure: 0x000fe710 signature: "_MP_" config_addr: 0x000f0000 length: 1 spec_rev: 4 supported checksum: 0x91 feature1: 0x00 Configuration structure present feature2: 0x00 Virtual Wire Mode Shared Processor Clock Source feature3: 0x00 feature4: 0x00 feature5: 0x00 Header Structure: 0x000f0000 signature: 0x504d4350 "PCMP" length: 0x27c spec_rev: 0x4 checksum: 0x2 oemid: "DELL " productid "PE 02A4 " oem_addr: 0x0 oem_size: 0x0 entry_count: 0x44 local_addr: 0xfee00000 Processor Entry: 0x000f002c local_id: 0x0 local_version: 0x15 usable: 1 bootstrap: 1 family: 6 model: 14 stepping: 5 features: 0xbfebfbff Processor Entry: 0x000f0040 local_id: 0x6 local_version: 0x15 usable: 1 bootstrap: 0 family: 6 model: 14 stepping: 5 features: 0xbfebfbff Processor Entry: 0x000f0054 local_id: 0x4 local_version: 0x15 usable: 1 bootstrap: 0 family: 6 model: 14 stepping: 5 features: 0xbfebfbff .... Local APIC 0 Normally this type display APIC ID: 0x00000000 would list things like NIC's APIC Version: 0x00060015 and SCSI controllers on the PCI Task Priority: 0x00000008 Bus (DeviceNum, Function, Bus, etc.). Arb Priority: 0x00000000 Proc Priority: 0x00000000 Remote Read: 0x00000000 Logical Dest: 0x01000000 Dest Format: 0xffffffff Spurious Int Vect: 0x0000016f In-Service: 0x00000000000000000000000000000000 0x00000000000000000000000000000000 Interrupt Req: 0x00000000000000000000000000000000 0x00000000000000000000000000000000 Trigger Mode: 0x00000000000000000000000000000000 0x00000000000000030000000000000000 Error Status: 0x00000000 Interrupt Command: 0x02000000000c0050 Timer: 0x00020050 Lint0: 0x00010000 Lint1: 0x00000400 Error: 0x00010000 Initial Count: 0x00144b3c Current Count: 0x00058e76 Timer Divide Conf: 0x0000000b Local APIC 1 APIC ID: 0x02000000 APIC Version: 0x00060015 Task Priority: 0x00000008 Arb Priority: 0x00000000 Proc Priority: 0x00000000 Remote Read: 0x00000000 Logical Dest: 0x02000000 Dest Format: 0xffffffff Spurious Int Vect: 0x0000016f In-Service: 0x00000000000000000000000000000000 0x00000000000000000000000000000000 Interrupt Req: 0x00000000000000000000000000000000 0x00000000000000000000000000000000 Trigger Mode: 0x00000000000000000000000000000000 0x00000000000000000000000000000000 Error Status: 0x00000000 Interrupt Command: 0x0400000000000042 Timer: 0x00010000 Lint0: 0x00010000 Lint1: 0x00010000 Error: 0x00010000 Initial Count: 0x00000000 Current Count: 0x00000000 Timer Divide Conf: 0x00000000 .... Report about console for dunix.testdom.com on Fri Mar 25 00:06:23 2011 Graphics card configuration File: /usr/lib/grafinfo/grafdev console, tty01, tty02, tty03, tty04, tty05, tty06, tty07, tty08, tty09, tty10, tty11, tty12 File: /usr/lib/grafinfo/vesa/svga.xgi Vendor: VESA Model: Matrox Graphics Inc. Class: VBE (3.0) Mode: 1024x768 256-color X Driver: svga Visual: PseudoColor Depth: 8 Width: 1024 Height: 768 Graphics display configuration File: /usr/lib/grafinfo/grafmon Info: vesa.svga:misc.standard Description: Standard VGA Vendor: misc Model: standard Width: 234 Height: 175 Type: color Mouse configuration Files: /usr/lib/event/ttys /usr/lib/event/devices .... %kernel - - - rel=3.2v5.0.7 kid=2003-02-18 %cpu - - - unit=1 family=6 type=gt PentIII %cpuid - - - unit=1 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - 13 - unit=1 type=80387-compatible %pci 0x0CF8-0x0CFF - - am=1 sc=0 buses=256 %PnP - - - nodes=0 %clock - - - type=TSC/2.659983184Ghz %serial 0x03F8-0x03FF 4 - unit=0 type=Standard nports=1 base=0 16550A/16 %serial 0x02F8-0x02FF 3 - unit=1 type=Standard nports=1 base=8 16550A/16 %console - - - unit=vga type=0 num=12 scoansi=1 scroll=50 %floppy 0x03F2-0x03F7 6 2 unit=0 type=135ds18 %udi - - - UDI environment %adapter - - - ha=0 type=usb_msto UDI SCSI HBA %adapter 0xFC00-0xFC80 11 0 type=lsil ha=0 id=112 Chip=1068E 10409 %adapter 0xECB0-0xECB7 14 - type=IDE ctlr=1 dvr=wd %bnxii0 - 11 - chip=5716C mem=DA000000 addr=78:2b:cb:0b:78:d4 %cd-rom - - - type=IDE ctlr=1 cfg=mst unit=0 dvr=Srom->wd %disk - - - type=S ha=0 id=0 lun=0 bus=0 ht=lsil unit=0 %Sdsk - - - cyls=17784 hds=255 secs=63 unit=0 fts=stdb %Sdsk-0 - - - Vnd=Dell Prd=VIRTUAL DISK Rev=1028 %cpu - 255 - unit=2 family=6 type=gt PentIII %cpuid - - - unit=2 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=2 type=80387-compatible %cpu - 255 - unit=3 family=6 type=gt PentIII %cpuid - - - unit=3 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=3 type=80387-compatible %cpu - 255 - unit=4 family=6 type=gt PentIII %cpuid - - - unit=4 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=4 type=80387-compatible (END I read somewhere in SCO tech articles that 5.0.7 MP supports a maximum of 4 CPU's. When I first got this installed, I saw 8 cpu's reported on boot: %cpu - 255 - unit=2 family=6 type=gt PentIII %cpuid - - - unit=2 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=2 type=80387-compatible %cpu - 255 - unit=3 family=6 type=gt PentIII %cpuid - - - unit=3 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=3 type=80387-compatible %cpu - 255 - unit=4 family=6 type=gt PentIII %cpuid - - - unit=4 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=4 type=80387-compatible %cpu - 255 - unit=5 family=6 type=gt PentIII %cpuid - - - unit=5 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=5 type=80387-compatible %cpu - 255 - unit=6 family=6 type=gt PentIII %cpuid - - - unit=6 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=6 type=80387-compatible %cpu - 255 - unit=7 family=6 type=gt PentIII %cpuid - - - unit=7 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=7 type=80387-compatible %cpu - 255 - unit=8 family=6 type=gt PentIII %cpuid - - - unit=8 vend=GenuineIntel tfms=0:6:14:5(0) %fpu - - - unit=8 type=80387-compatible So I reset BIOS to disable "virtual CPU" (Possibly a euphemism for Hyper Threading 4 cores + hyper threading = 8 logical CPU's) to bring the count back down to 4. As I was worried about the max 4 CPU's in the SCO documentation. Mpstat when booted with 8 virtual processors shows results on six processors. This was not an easy install and required a lot of work around to get past the USB keyboard lock-up and inability to load the btld for wd and lsil drivers from a USB floppy during ISL. I'd welcome comments on sticking with 4 cores with HT disabled, enable only two cores with HT, or just let it run wide open 4 cores with HT (8 logical processors)? Which option would perform best with 5.0.7? -- Steve Fabac S.M. Fabac & Associates 816/765-1670

In article <4D8C3C66.7080108@att.net> "Steve M. Fabac, Jr." <smfabac@att.net> writes: $So I reset BIOS to disable "virtual CPU" (Possibly a euphemism for $Hyper Threading 4 cores + hyper threading = 8 logical CPU's) to $bring the count back down to 4. As I was worried about the $max 4 CPU's in the SCO documentation. Yes, "virtual CPU" would mean hyperthreading. I've never tried running 5.0.7 on a system with that many "CPUs" (I've used it on a quad-core CPU that does not support hyperthreading, and on a single-core CPU that does, but never on a hyperthreaded quad-core CPU), but hw is telling you that the maximum supported is 10 while the documentation says 4. So I'm not sure what to believe is the actual maximum. $Mpstat when booted with 8 virtual processors shows results $on six processors. The mpstat man page says it may be limited as to how many CPUs it can display on one screen, depending on the size of your screen, and gives keystrokes that are supposed to let you navigate through its display in such a case. Give that a shot and see if it works (or try running it on a more-than-25-line screen). $I'd welcome comments on sticking with 4 cores with HT disabled, $enable only two cores with HT, or just let it run wide open $4 cores with HT (8 logical processors)? Which option would $perform best with 5.0.7? If you are actually limited to 4, you definitely want to go with four cores and no hyperthreading. Each core is a complete CPU, competing with the others only for access to some cache levels (depending on what architecture you're using) and access to off-chip resources such as memory and I/O. Two threads of operation running on the same core via hyperthreading, on the other hand, have to compete for all of the core's resources, including the functional units which actually do the computation and any cache levels which are dedicated to a specific core. FWIW, I did a test with a real-world application (a Photoshop plug-in which is very CPU- and memory-intensive) back in the days when my home machine was a hyperthreaded P4. The plug-in is multithreaded. With hyperthreading enabled and the plug-in configured to use two threads, it performed about 10% better than with hyperthreading disabled and the plug-in configured to use one thread. The actual performance difference for any particular application, of course, will depend on the application, but this should illustrate that hyperthreading typically provides a modest speed increase: it's better than nothing, but not as good as an additional core (which won't get you a 100% boost but should typically be closer to 100% than to 10%). I don't know how smart 5.0.7's scheduler is with respect to hyperthreading. Any MP scheduler ought to be able to utilize a hyperthreaded CPU, as the information the OS gets from the hardware/firmware will list (in your case) 8 CPUs. However, if the scheduler isn't aware of hyperthreading, it may do something dumb like scheduling two processes for the two virtual CPUs on the same core while leaving other cores completely idle, because it simply doesn't know any better. If the scheduler is aware of hyperthreading, on the other hand, it will know which virtual CPUs share the same physical core, and should generally avoid scheduling two processes on the same physical core if possible (i.e. if the number of runnable processes is no greater than the number of physical cores, then it should schedule them on separate cores; processes should only be dispatched to the second virtual CPU on any core if all cores are currently running at least one process). I believe one of the 5.0.7 MPs included official support for hyperthreading. I don't know what, exactly, that support includes. That probably means that the scheduler was enhanced to be aware of how best to schedule processes on a hyperthreaded CPU, in which case it should do the right thing. If that's the case, then the best thing to do is to enable hyperthreading and all cores, subject to whatever the actual OS limit is. As to what the actual limit is, it looks to me like four hyperthreaded cores is OK. After all, the boot-time hardware display has no problem with it, and you managed to run the system this way without it blowing up. I suppose you could always do a bit more of a test by doing something that chews up CPU cycles and running multiple copies of it to see if the system survives. Running eight copies of this should keep all the CPUs pretty busy, for instance: while true do compress -H </dev/mem >/dev/null done But my guess about the actual limit is just a guess. If you want to be the safest, then take the most restrictive limit SCO documents (which appears to be four) and go with that: four cores, no hyperthreading. You may not use your CPU to its fullest, but you should be safe. -- Stephen M. Dunn <stephen@stevedunn.ca> >>>----------------> http://www.stevedunn.ca/ <----------------<<< ------------------------------------------------------------------ Say hi to my cat -- http://www.stevedunn.ca/photos/prince/

Stephen M. Dunn wrote: > In article <4D8C3C66.7080108@att.net> "Steve M. Fabac, Jr." <smfabac@att.net> writes: > $So I reset BIOS to disable "virtual CPU" (Possibly a euphemism for > $Hyper Threading 4 cores + hyper threading = 8 logical CPU's) to > $bring the count back down to 4. As I was worried about the > $max 4 CPU's in the SCO documentation. > > Yes, "virtual CPU" would mean hyperthreading. I've never tried > running 5.0.7 on a system with that many "CPUs" (I've used it on a > quad-core CPU that does not support hyperthreading, and on a single-core > CPU that does, but never on a hyperthreaded quad-core CPU), but > hw is telling you that the maximum supported is 10 while the documentation > says 4. So I'm not sure what to believe is the actual maximum. The OSR5 kernel design limit is 30 (certain 1-bit-per-CPU variables are stored in 32-bit ints with 2 bits dedicated to other uses). At the time that the 4-CPU limit was documented, OSR5 had never been *tested* with more than 4 CPUs. There were no resources to do such testing and only ridiculously expensive super-high-end hardware had any pretense to offering more than 4 CPUs, so the tested limit was documented in stone. Obviously if it will actually recognize 8 at boot time then the limit was not hard-encoded in the software... > I don't know how smart 5.0.7's scheduler is with respect to > hyperthreading. Any MP scheduler ought to be able to utilize > a hyperthreaded CPU, as the information the OS gets from the > hardware/firmware will list (in your case) 8 CPUs. However, > if the scheduler isn't aware of hyperthreading, it may do something > dumb like scheduling two processes for the two virtual CPUs on > the same core while leaving other cores completely idle, because > it simply doesn't know any better. If the scheduler is aware > of hyperthreading, on the other hand, it will know which virtual > CPUs share the same physical core, and should generally avoid > scheduling two processes on the same physical core if possible (i.e. > if the number of runnable processes is no greater than the number of > physical cores, then it should schedule them on separate cores; > processes should only be dispatched to the second virtual CPU on > any core if all cores are currently running at least one process). > > I believe one of the 5.0.7 MPs included official support for > hyperthreading. I don't know what, exactly, that support includes. That > probably means that the scheduler was enhanced to be aware of how best to > schedule processes on a hyperthreaded CPU, in which case it should do the > right thing. If that's the case, then the best thing to do is to enable > hyperthreading and all cores, subject to whatever the actual OS limit is. HT support was added at some point. I believe this consisted of the following: - improving the scheduler along the lines you mention (but more below) - changing the license code to count "two halves" of a hyperthreaded CPU as equal to one CPU license - cosmetic changes to describe things correctly (more or less) What you describe for an HT-aware scheduler is part of the puzzle. Let's look at a few examples. In all cases the hardware is 2 physical CPUs which have HT (thus 4 total threads). I'm going to talk about this in terms of software "threads" -- these could be individual single-threaded processes or threads of a multithreaded process. First, suppose you are running two CPU-chewing threads that are completely unrelated: you want those on separate cores so each gets the full attention of a whole CPU. Now suppose you're running 2 CPU-chewing threads of the same process, and they're working on the same data in the same memory area. If you schedule both on the same physical CPU (on the two HT "halves"), you get much better cache synergy. They share 1st-level and possibly 2nd-level cache (depending on the CPU model). So now the benefit depends greatly on locality of reference. If both threads are reading and writing out of the same small area (fits entirely within the CPU's internal caches), sharing a single HT core may be *faster* than separate cores. Or it may not. In any case, the benefit will be considerably higher than 10%. Now suppose you're running *3* busy threads, and two have good cache sharing while the 3rd is totally unrelated. Now it is extremely likely that the best system throughput will come from ganging the related threads onto one core. Yet this may give the 3rd thread an unfair advantage in total throughput. A more sophisticated scheduler may shuffle the threads around occasionally to impede the 3rd thread so it isn't unfairly advantaged. Or it may recognize the situation and schedule all *other* low-activity threads, as they wake up, to take time away from thread #3 only. And it will do all of this dynamically and with a lot of monitoring so it has a pretty good idea of how its various actions are actually playing out. So. As far as I know, the OSR5 "HT aware" scheduler is about as simple as an HT scheduler could be. I don't think it does anything more sophisticated than this: when looking to place a thread onto a CPU, if any CPU has both halves idle, choose one of those halves. Otherwise all available CPUs are sharing with something -- consider these all equally not-very-good, choose one without further regard to what's running where. (In that case the next criterion would almost certainly be: if available, choose the same CPU thread this process thread last used.) > As to what the actual limit is, it looks to me like four > hyperthreaded cores is OK. After all, the boot-time hardware > display has no problem with it, and you managed to run the system > this way without it blowing up. I suppose you could always do a > bit more of a test by doing something that chews up CPU cycles > and running multiple copies of it to see if the system survives. > Running eight copies of this should keep all the CPUs pretty busy, > for instance: > > while true > do > compress -H </dev/mem >/dev/null > done This would have been a guaranteed crash at some point in OSR5's history; also Linux's, for that matter. /dev/mem is linear mapping of physical memory. Starting at 640KiB through 1MiB, you're reading memory-mapped I/O ports. Some devices in that range (especially on older hardware) will go crazy when you do this. I believe that the current versions of "/dev/mem" driver on both OSR5 and Linux intentionally skip those regions unless you do something active (like a "yes I know what I'm doing" ioctl). > FWIW, I did a test with a real-world application (a Photoshop > plug-in which is very CPU- and memory-intensive) back in the days > when my home machine was a hyperthreaded P4. The plug-in is > multithreaded. With hyperthreading enabled and the plug-in > configured to use two threads, it performed about 10% better than > with hyperthreading disabled and the plug-in configured to use > one thread. The actual performance difference for any particular > application, of course, will depend on the application, but this > should illustrate that hyperthreading typically provides a modest > speed increase: it's better than nothing, but not as good as > an additional core (which won't get you a 100% boost but should > typically be closer to 100% than to 10%). Supposedly -- and I have seen some research to support this -- the new version of HT reintroduced with Nehalem is significantly more efficient. The first HT CPUs (Foster or Willamette) were good for something like 1.05 CPU each. Modern HT cores should be good for like 1.2 CPU, maybe a bit more depending on application and various other factors. I suspect that it's possible to carefully craft code that will run nearly twice as fast with HT -- but that's not what you get with standard compilation and various process mixes. >Bela<

Bela Lubkin wrote: > Stephen M. Dunn wrote: > >> In article <4D8C3C66.7080108@att.net> "Steve M. Fabac, Jr." <smfabac@att.net> writes: >> $So I reset BIOS to disable "virtual CPU" (Possibly a euphemism for >> $Hyper Threading 4 cores + hyper threading = 8 logical CPU's) to >> $bring the count back down to 4. As I was worried about the >> $max 4 CPU's in the SCO documentation. >> >> Yes, "virtual CPU" would mean hyperthreading. I've never tried >> running 5.0.7 on a system with that many "CPUs" (I've used it on a >> quad-core CPU that does not support hyperthreading, and on a single-core >> CPU that does, but never on a hyperthreaded quad-core CPU), but >> hw is telling you that the maximum supported is 10 while the documentation >> says 4. So I'm not sure what to believe is the actual maximum. > > The OSR5 kernel design limit is 30 (certain 1-bit-per-CPU variables are > stored in 32-bit ints with 2 bits dedicated to other uses). > > At the time that the 4-CPU limit was documented, OSR5 had never been > *tested* with more than 4 CPUs. There were no resources to do such > testing and only ridiculously expensive super-high-end hardware had any > pretense to offering more than 4 CPUs, so the tested limit was > documented in stone. > > Obviously if it will actually recognize 8 at boot time then the limit > was not hard-encoded in the software... Bela, Thanks for your input on this. Just one more question if I can: The SCO tuning guide recommends doubling NHBUF (as a power of 2) to twice the size of NBUF. That's where their guidance on this stops. They list the case of SMP with NBUF at 32000 and recommend setting NHBUI to 65536. So looking at mtune I see default min and max values for NBUF and NHBUF: NBUF 0 24 450000 NHBUF 0 32 524288 I subscribe to the school that it a good idea to throw as much ram to disk buffers as possible. Especially when replacing an old server with 512M of RAM with one with 4G. So I set NBUF to 130000 and NHBUF to 524288 based upon dividing 524288 by CPU's (4 in this case) and then rounding the value down to an even value. bc 2^6 65536 2^7 131072 2^8 262144 2^9 524288 524288 / 4 131072 = 130000 for NBUF Would you agree with that or recommend going back to NBUF = 0 and NHBUF = 0 and letting the OS have its way with it? From the /usr/adm/syslog you can see that if the kernel is allowed to tune NBUF, the required value for NHBUF for two CPU's would exceed the maximum specified in mtune. ISL Mar 24 15:13:48 unix kernel: Hz = 100, i/o bufs = 313188k (high bufs = 312164k) Mar 24 15:23:03 unix kernel: Hz = 100, i/o bufs = 313188k (high bufs = 312164k) SMP and MP5 installed Mar 24 15:52:22 unix kernel: Hz = 100, i/o bufs = 313124k (high bufs = 312100k) Mar 24 16:09:46 unix kernel: Hz = 100, i/o bufs = 313124k (high bufs = 312100k) Mar 24 16:22:07 unix kernel: Hz = 100, i/o bufs = 313124k (high bufs = 312100k) Mar 24 16:29:58 unix kernel: Hz = 100, i/o bufs = 313124k (high bufs = 312100k) Mar 24 16:39:40 unix kernel: Hz = 100, i/o bufs = 313124k (high bufs = 312100k) bnxii0 Network driver installed Mar 24 17:25:51 unix kernel: Hz = 100, i/o bufs = 313084k (high bufs = 312060k) Mar 24 17:53:23 unix kernel: Hz = 100, i/o bufs = 313084k (high bufs = 312060k) Mar 25 13:32:44 unix kernel: Hz = 100, i/o bufs = 313084k (high bufs = 312060k) Mar 27 23:00:01 unix kernel: Hz = 100, i/o bufs = 313084k (high bufs = 312060k) Mar 27 23:04:49 unix kernel: Hz = 100, i/o bufs = 313084k (high bufs = 312060k) Disabled usb_ehci, usb_ohci, usb_uhci in conf/pack.d/sdevice.d to allow removing "disable=usb_uhic,usb_ehci,usb_ohci" in the default kernel boot string so that Microlite RE2 will boot with out requiring the use of defbootstr commands (and allowed removing from /etc/default/boot as well). Mar 28 00:03:10 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 28 00:08:03 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 28 00:17:27 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 28 00:24:10 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 28 00:31:42 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 28 02:25:09 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 29 01:11:16 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 29 14:46:00 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 29 15:10:18 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Mar 29 15:48:06 unix kernel: Hz = 100, i/o bufs = 313092k (high bufs = 312068k) Set NBUF and NHBUF for 4 CPU's Mar 31 00:05:14 unix kernel: Hz = 100, i/o bufs = 130000k (high bufs = 128976k) Mar 31 07:34:01 unix kernel: Hz = 100, i/o bufs = 130000k (high bufs = 128976k) Mar 31 11:11:30 unix kernel: Hz = 100, i/o bufs = 130000k (high bufs = 128976k) Mar 31 12:38:10 unix kernel: Hz = 100, i/o bufs = 130000k (high bufs = 128976k) Mar 31 14:03:40 unix kernel: Hz = 100, i/o bufs = 130000k (high bufs = 128976k) Mar 31 14:40:07 unix kernel: Hz = 100, i/o bufs = 130000k (high bufs = 128976k) Mar 31 15:29:48 unix kernel: Hz = 100, i/o bufs = 130000k (high bufs = 128976k) > >> I don't know how smart 5.0.7's scheduler is with respect to >> hyperthreading. Any MP scheduler ought to be able to utilize >> a hyperthreaded CPU, as the information the OS gets from the >> hardware/firmware will list (in your case) 8 CPUs. However, >> if the scheduler isn't aware of hyperthreading, it may do something >> dumb like scheduling two processes for the two virtual CPUs on >> the same core while leaving other cores completely idle, because >> it simply doesn't know any better. If the scheduler is aware >> of hyperthreading, on the other hand, it will know which virtual >> CPUs share the same physical core, and should generally avoid >> scheduling two processes on the same physical core if possible (i.e. >> if the number of runnable processes is no greater than the number of >> physical cores, then it should schedule them on separate cores; >> processes should only be dispatched to the second virtual CPU on >> any core if all cores are currently running at least one process). >> >> I believe one of the 5.0.7 MPs included official support for >> hyperthreading. I don't know what, exactly, that support includes. That >> probably means that the scheduler was enhanced to be aware of how best to >> schedule processes on a hyperthreaded CPU, in which case it should do the >> right thing. If that's the case, then the best thing to do is to enable >> hyperthreading and all cores, subject to whatever the actual OS limit is. > > HT support was added at some point. I believe this consisted of the > following: > > - improving the scheduler along the lines you mention (but more below) > - changing the license code to count "two halves" of a hyperthreaded CPU > as equal to one CPU license > - cosmetic changes to describe things correctly (more or less) > > What you describe for an HT-aware scheduler is part of the puzzle. > Let's look at a few examples. In all cases the hardware is 2 physical > CPUs which have HT (thus 4 total threads). I'm going to talk about this > in terms of software "threads" -- these could be individual > single-threaded processes or threads of a multithreaded process. > > First, suppose you are running two CPU-chewing threads that are > completely unrelated: you want those on separate cores so each gets the > full attention of a whole CPU. > > Now suppose you're running 2 CPU-chewing threads of the same process, > and they're working on the same data in the same memory area. If you > schedule both on the same physical CPU (on the two HT "halves"), you get > much better cache synergy. They share 1st-level and possibly 2nd-level > cache (depending on the CPU model). So now the benefit depends greatly > on locality of reference. If both threads are reading and writing out > of the same small area (fits entirely within the CPU's internal caches), > sharing a single HT core may be *faster* than separate cores. Or it may > not. In any case, the benefit will be considerably higher than 10%. > > Now suppose you're running *3* busy threads, and two have good cache > sharing while the 3rd is totally unrelated. Now it is extremely likely > that the best system throughput will come from ganging the related > threads onto one core. Yet this may give the 3rd thread an unfair > advantage in total throughput. A more sophisticated scheduler may > shuffle the threads around occasionally to impede the 3rd thread so it > isn't unfairly advantaged. Or it may recognize the situation and > schedule all *other* low-activity threads, as they wake up, to take > time away from thread #3 only. And it will do all of this dynamically > and with a lot of monitoring so it has a pretty good idea of how its > various actions are actually playing out. > > So. As far as I know, the OSR5 "HT aware" scheduler is about as simple > as an HT scheduler could be. I don't think it does anything more > sophisticated than this: when looking to place a thread onto a CPU, if > any CPU has both halves idle, choose one of those halves. Otherwise all > available CPUs are sharing with something -- consider these all equally > not-very-good, choose one without further regard to what's running > where. (In that case the next criterion would almost certainly be: if > available, choose the same CPU thread this process thread last used.) > >> As to what the actual limit is, it looks to me like four >> hyperthreaded cores is OK. After all, the boot-time hardware >> display has no problem with it, and you managed to run the system >> this way without it blowing up. I suppose you could always do a >> bit more of a test by doing something that chews up CPU cycles >> and running multiple copies of it to see if the system survives. >> Running eight copies of this should keep all the CPUs pretty busy, >> for instance: >> >> while true >> do >> compress -H </dev/mem >/dev/null >> done > > This would have been a guaranteed crash at some point in OSR5's history; > also Linux's, for that matter. /dev/mem is linear mapping of physical > memory. Starting at 640KiB through 1MiB, you're reading memory-mapped > I/O ports. Some devices in that range (especially on older hardware) > will go crazy when you do this. I believe that the current versions of > "/dev/mem" driver on both OSR5 and Linux intentionally skip those > regions unless you do something active (like a "yes I know what I'm > doing" ioctl). > >> FWIW, I did a test with a real-world application (a Photoshop >> plug-in which is very CPU- and memory-intensive) back in the days >> when my home machine was a hyperthreaded P4. The plug-in is >> multithreaded. With hyperthreading enabled and the plug-in >> configured to use two threads, it performed about 10% better than >> with hyperthreading disabled and the plug-in configured to use >> one thread. The actual performance difference for any particular >> application, of course, will depend on the application, but this >> should illustrate that hyperthreading typically provides a modest >> speed increase: it's better than nothing, but not as good as >> an additional core (which won't get you a 100% boost but should >> typically be closer to 100% than to 10%). > > Supposedly -- and I have seen some research to support this -- the new > version of HT reintroduced with Nehalem is significantly more efficient. > The first HT CPUs (Foster or Willamette) were good for something like > 1.05 CPU each. Modern HT cores should be good for like 1.2 CPU, maybe a > bit more depending on application and various other factors. I suspect > that it's possible to carefully craft code that will run nearly twice as > fast with HT -- but that's not what you get with standard compilation > and various process mixes. > >> Bela< > > -- Steve Fabac S.M. Fabac & Associates 816/765-1670

Steve M. Fabac, Jr. wrote: > Thanks for your input on this. Just one more question if I can: Really a completely unrelated thread... > The SCO tuning guide recommends doubling NHBUF (as a power of 2) > to twice the size of NBUF. That's where their guidance on this > stops. They list the case of SMP with NBUF at 32000 and recommend > setting NHBUI to 65536. Take that recommendation with a shovel of salt. It's based on a generic computer science classroom observation that hash table access is faster if the table is sparse; that is, if each hash bucket contains 1 or less items on average. Also, if the hash is being accessed by multiple CPUs with a locking scheme, the penalty for shared hashes is higher, so it's good to make it even sparser. This would potentially matter a lot if your system was spending a significant amount of time in the buffer cache hash chain walking routines. But it isn't. I promise. I doubt your 4-CPU box is even using one whole core's worth of power, averaged over time. Even if the CPUs *are* busy, and you're doing lots of disk I/O, and most of that is being satisfied out of the buffer cache -- still, only a minuscule fraction of time will be spent in those routines. THEREFORE, even if you set NHBUF to, say, 256, you probably won't ever notice the difference. NBUF has a max value of 450000. With NHBUF=256, that's nearly 2000 items per bucket; any lookup, insertion or deletion is going to follow a linked list for an average of ~1000 steps. I went disassembling, the lookup version of this loop is 11 instructions long and probably < 30 clocks. So 30K clock cycles on average, or 1/100000 of a second on a 3GHz processor. When are you doing a lookup? You've just done a physical disk read, are about to do a physical disk write, or the buffer cache is standing in for one of those operations. The physical operations probably take about 5-10ms, so we're adding an irrelevant overhead of 1/1000 to 1/500 more. In the pure buffer cache case we're adding a larger overhead, but still not very significant. Meanwhile, it's 8 bytes per hash bucket, so the max of 512K NHBUF = 4MiB of RAM. 1/1024 of your total, not very relevant, but still wasteful. If NBUF=450000 and NHBUF=32768, the average chain is 14 buffers long. The average overhead of ~400 clocks will be totally lost in the rest of the overhead of going into the kernel, going up and down the filesystem, buffer cache etc. routines. If you set NHBUF to its minimum of 32, you might be able to measure a difference. I'd be curious to see... Of course scrimping on NHBUF only makes sense if you are RAM-limited, which you probably aren't. Run `sar -r 1 3`, look at "freemem". That's in 4KiB memory pages. The machine I'm posting from has 3.5GiB of RAM and freemem is hovering around 615000 = 2.5GiB. If you'd told me in 1990 that I would have a machine with 2.5 gigabytes of completely unused RAM, I'd think you were crazy... > So looking at mtune I see default min and max values for NBUF and > NHBUF: > > NBUF 0 24 450000 > NHBUF 0 32 524288 > > I subscribe to the school that it a good idea to throw as > much ram to disk buffers as possible. Especially when > replacing an old server with 512M of RAM with one with > 4G. So I set NBUF to 130000 and NHBUF to 524288 based > upon dividing 524288 by CPU's (4 in this case) and then > rounding the value down to an even value. Whoa there. "good idea to throw as much ram to disk buffers", OK, I'm with you on that. But then you only throw it 130K buffers when the limit is 450K! NBUF is far more likely to have a measurable performance effect. You want to crank it all the way up unless you have a very specific reason not to (e.g. your process workloads are big enough to cause swapping). > Would you agree with that or recommend going back to > NBUF = 0 and NHBUF = 0 and letting the OS have its > way with it? From the /usr/adm/syslog you can see > that if the kernel is allowed to tune NBUF, the required > value for NHBUF for two CPU's would exceed the maximum > specified in mtune. The kernel autotune here is incredibly conservative. It can't autotune NBUF to 450000, you'd need ~6GiB RAM for the formula to reach 450K, and OSR5 doesn't support that. For NHBUF it makes these wild assumptions about how significant it is, when it isn't. > Mar 24 15:13:48 unix kernel: Hz = 100, i/o bufs = 313188k (high bufs = 312164k) Ohhhh.... are you relating NHBUF to "high bufs" here? No relation. "high bufs" are buffers outside the first 16MiB, the ISA DMA range. You'll notice that all but 1024 of yours are high, presumably by autotune decision. Low/high only matters if the driver that does the physical I/O uses ISA DMA. I can think of three popular drivers that ever did so (there were dozens of unpopular ones like Future Domain HBAs or whatever). The popular ones: "ad" for Adaptec 154x HBA, "ct" for QIC-24 etc. tape controllers, and "fd" for floppy drives. Hmmm, possibly "blc" for BusLogic, but I bet it knows not to demand ISA DMA buffers for the PCI version of the adapter (which is what various virtual machines emulate). "fd" is the only one you're likely to ever light up these days. It will be happy with a couple handfuls of buffers. So don't worry about high bufs. They're what you want. >Bela<

Bela Lubkin wrote: > Steve M. Fabac, Jr. wrote: > >> Thanks for your input on this. Just one more question if I can: > > Really a completely unrelated thread... > >> The SCO tuning guide recommends doubling NHBUF (as a power of 2) >> to twice the size of NBUF. That's where their guidance on this >> stops. They list the case of SMP with NBUF at 32000 and recommend >> setting NHBUI to 65536. > > Take that recommendation with a shovel of salt. It's based on a generic > computer science classroom observation that hash table access is faster > if the table is sparse; that is, if each hash bucket contains 1 or less > items on average. Also, if the hash is being accessed by multiple CPUs > with a locking scheme, the penalty for shared hashes is higher, so it's > good to make it even sparser. > > This would potentially matter a lot if your system was spending a > significant amount of time in the buffer cache hash chain walking > routines. But it isn't. I promise. I doubt your 4-CPU box is even > using one whole core's worth of power, averaged over time. > > Even if the CPUs *are* busy, and you're doing lots of disk I/O, and most > of that is being satisfied out of the buffer cache -- still, only a > minuscule fraction of time will be spent in those routines. > > THEREFORE, even if you set NHBUF to, say, 256, you probably won't ever > notice the difference. > > NBUF has a max value of 450000. With NHBUF=256, that's nearly 2000 > items per bucket; any lookup, insertion or deletion is going to follow a > linked list for an average of ~1000 steps. I went disassembling, the > lookup version of this loop is 11 instructions long and probably < 30 > clocks. So 30K clock cycles on average, or 1/100000 of a second on a > 3GHz processor. > > When are you doing a lookup? You've just done a physical disk read, are > about to do a physical disk write, or the buffer cache is standing in > for one of those operations. > > The physical operations probably take about 5-10ms, so we're adding an > irrelevant overhead of 1/1000 to 1/500 more. > > In the pure buffer cache case we're adding a larger overhead, but still > not very significant. > > Meanwhile, it's 8 bytes per hash bucket, so the max of 512K NHBUF = 4MiB > of RAM. 1/1024 of your total, not very relevant, but still wasteful. > > If NBUF=450000 and NHBUF=32768, the average chain is 14 buffers long. > The average overhead of ~400 clocks will be totally lost in the rest of > the overhead of going into the kernel, going up and down the filesystem, > buffer cache etc. routines. > > If you set NHBUF to its minimum of 32, you might be able to measure a > difference. I'd be curious to see... > > Of course scrimping on NHBUF only makes sense if you are RAM-limited, > which you probably aren't. Run `sar -r 1 3`, look at "freemem". That's > in 4KiB memory pages. The machine I'm posting from has 3.5GiB of RAM > and freemem is hovering around 615000 = 2.5GiB. If you'd told me in > 1990 that I would have a machine with 2.5 gigabytes of completely unused > RAM, I'd think you were crazy... > >> So looking at mtune I see default min and max values for NBUF and >> NHBUF: >> >> NBUF 0 24 450000 >> NHBUF 0 32 524288 >> >> I subscribe to the school that it a good idea to throw as >> much ram to disk buffers as possible. Especially when >> replacing an old server with 512M of RAM with one with >> 4G. So I set NBUF to 130000 and NHBUF to 524288 based >> upon dividing 524288 by CPU's (4 in this case) and then >> rounding the value down to an even value. > > Whoa there. "good idea to throw as much ram to disk buffers", OK, I'm > with you on that. But then you only throw it 130K buffers when the > limit is 450K! I'm still analyzing your information on the time spent in processing the buffer cache and has buffers above. It may eventually make sense to me. As to setting NHBUF to 130000: looked like a reasonable conclusion based upon an outsider reading the tuning guide example and deducing that if NHBUF can only reach 524288 (as tuned in stune) then to insure that each processor can have its own hash table of NBUF I need to set NBUF to 1/4 (for 4 CPUs) of the maximum derived from the maximum value I can set for NHBUF. > > NBUF is far more likely to have a measurable performance effect. You > want to crank it all the way up unless you have a very specific reason > not to (e.g. your process workloads are big enough to cause swapping). Ok, I take it from your comments that you would recommend setting NBUF to 450000 and setting NHBUF to 0 and let the kernel do what it wants with the result. > >> Would you agree with that or recommend going back to >> NBUF = 0 and NHBUF = 0 and letting the OS have its >> way with it? From the /usr/adm/syslog you can see >> that if the kernel is allowed to tune NBUF, the required >> value for NHBUF for two CPU's would exceed the maximum >> specified in mtune. > > The kernel autotune here is incredibly conservative. It can't autotune > NBUF to 450000, you'd need ~6GiB RAM for the formula to reach 450K, and > OSR5 doesn't support that. For NHBUF it makes these wild assumptions > about how significant it is, when it isn't. > >> Mar 24 15:13:48 unix kernel: Hz = 100, i/o bufs = 313188k (high bufs = 312164k) > > Ohhhh.... are you relating NHBUF to "high bufs" here? No relation. > "high bufs" are buffers outside the first 16MiB, the ISA DMA range. > You'll notice that all but 1024 of yours are high, presumably by > autotune decision. No, the table was only meant to show what the kernel did with auto tuning NBUF during the stages of the installation and configuration until I hit upon the (now discredited) decision to set NBUF to 130000. The values auto tuned for i/o bufs seemed to imply that the SMP kernel did not follow the tuning recommendations for SMP of being able to allocate NBUF * 2 (to next higher power of 2) to NHBUF as clearly 313124 * 2 is already greater then the 524288 stune maximum limit. >> SMP and MP5 installed >> Mar 24 15:52:22 unix kernel: Hz = 100, i/o bufs = 313124k (high bufs = 312100k) To the outside observer: either the kernel auto tuning does not subscribe to the SMP tuning guide or it uses some other logic to calculate NBUF and derive a usable NHBUF. As evidence we see auto tuning setting 313188k prior to installing SMP and 313124k imediately after installing SMP and booting with all four cores and HT active for a count of 8 CPU's. > > Low/high only matters if the driver that does the physical I/O uses ISA > DMA. I can think of three popular drivers that ever did so (there were > dozens of unpopular ones like Future Domain HBAs or whatever). The > popular ones: "ad" for Adaptec 154x HBA, "ct" for QIC-24 etc. tape > controllers, and "fd" for floppy drives. Hmmm, possibly "blc" for > BusLogic, but I bet it knows not to demand ISA DMA buffers for the PCI > version of the adapter (which is what various virtual machines > emulate). > > "fd" is the only one you're likely to ever light up these days. Not on the Dell T310 as the only option is USB external floppy and to get SCO to boot you have to disable all the USB controllers: either by setting them to "N" in sdevice.d/usb_*hci and rebuilding the kernel or always use defbootstr disable=usb_ehci,usb_ohci,usb_uhci in /etc/default/boot. Installing SCO 5.0.7 on the T310 required MAGIC (to be explained at a later time if anyone is interested). > > It will be happy with a couple handfuls of buffers. > > So don't worry about high bufs. They're what you want. > >> Bela< > > -- Steve Fabac S.M. Fabac & Associates 816/765-1670

RedGrittyBrick wrote: > On 01/04/2011 15:46, Steve M. Fabac, Jr. wrote: >> Installing SCO 5.0.7 on the T310 required MAGIC (to be explained at >> a later time if anyone is interested). > > They are. > The client selected Dell as the server of choice. I checked the SCO Hardware compatibility matrix and see that T300 is the last "Certified" Dell server listed. The T300 shows installation with an external USB floppy drive and USB keyboard with the default boot string of link="lsil wd" with a 500G SATA drive on the PERC 6/iR controller. Bummer, the T300 is out of manufacture and the client only wants new equipment. The PERC 6/iR is still available and so we ordered the T310 with the 6/iR controller, two 146G SAS drives in RAID-1, Dell DVD writer (SATA) and the add-in LSI U320 SCSI controller (the client is currently using a SCSI tape drive for backup), big mistake: The LSI U320 SCSI controller resulted in "warning: no root hard disk controller" when trying to install even after reading the lsil bootload driver. So I pulled the U320 controller. The MAGIC is that the SCO software installation hangs at the message "Press enter to begin installation" after the boot-up splash screen lists the hardware. It appears that the USB keyboard driver in the July 2005 CD1 recut image does not properly initialize the Dell USB hardware. If you leave USB enabled in the install kernel it will always lock up after you press enter as directed: Keyboard goes dead, num-lock led goes off, num-lock and caps-lock key press ignored. The only option is power off. To get around this you must use: defbootstr link="lsil wd" disable=usb_ehci,usb_ohci,usb_uhci when booting the July 2005 recut install CD and a floppy disk with the btld.1.img from OSR507_SubCD_BTLD.iso in the external USB floppy drive. It seems counter-intuitive to disable the SCO USB drivers but the Dell BIOS must present the USB keyboard as a PS2 keyboard to the SCO kernel allowing you to continue the installation by entering the information during the subsequent ISL configuration. The lsil and wd bootload files are accessed before the install kernel initializes and are linked into the kernel before you get to the "press enter..." message. Here is the rest of the solution: After you press enter to continue the installation you answer the configuration questions (license, differ network, scologin off, etc) and the installation proceeds but then hits the message to "insert lsil boot media" (may be "boot floppy," may be something similar as I did not write it down). The choices are fd0, fd1, and when that fails because the usb floppy can't work with the in-kernel usb drivers disabled, it offers you the choice of retry, skip, or cancel. Cancel aborts the installation, retry never works, and skip completes the installation without loading the lsil and wd drivers into the link kit. So the first kernel built will not boot beyond the "no root hard disk controller" message. A real catch-22. The only way around this is to perform a btldinstall of the lsil and wd drivers from the btld.1.img floppy to another 5.0.7 system. Rebuild the kernel. Copy /stand to /tmp/stand, copy btld.1.img file to /tmp, copy the MP5 VOL's to /tmp/mp5, copy the bnxii_4.6.0/VOL.000.000 NIC driver from SCO to /tmp/net, then use BackupEdge to backup up a single directory to CDR media selecting /tmp and making the backup bootable. Boot the backup CD on the Dell with defbootstr Sdsk=lsil(0,0,0,0) Srom=wd(0,0,0) disable=usb_ehci,usb_ohci,usb_uhci Then when the RE2 image loads and finds the CD media, select utilities -> shell, mount /dev/hd0root on /mnt, cd to /mnt/tmp and execute edge xvbf 64 /dev/cd0 to restore the tmp backup to /mnt/tmp/tmp. When that restore is finished, mount /dev/boot on /mnt/stand, then copy /mnt/tmp/tmp/stand/unix to /mnt/stand/unix.lsil. Unmount all file systems, shut the system down and reboot the hard disk with: unix.lsil Sdsk=lsil(0,0,0,0) Srom=wd(0,0,0) disable=usb_ehci,usb_ohci,usb_uhci Enter the root password you gave the system on ISL and enter maintenance mode. Use marry -a /tmp/tmp/btld.1.img mount /dev/marry/tmp/tmp/btld.1.img /mnt btldinstall /mnt At the prompt: The following packages are on this disk: NAME DESCRIPTION aacraid Adaptec SCSI Raid driver for 5400, 2200 and 2120 series ad320 Adaptec 39320 29320 AIC-7901,7902 iir Intel Storage RAID Controller lsil LSI Logic 53C1020 53C1030 FC929 FC919 FC909 Host Adapters slha LSI Logic / Symbios Logic / NCR MPD 53c8xx Host Adapters wd Enhanced IDE and ATAPI Please enter the names of the packages you wish to install, or q to quit: lsil wd Enter lsil and wd as shown above and hit enter. When prompted relink the kernel and install it and rebuild the kernel environment. Edit /etc/default/boot and add disable=usb_ehci,usb_ohci,usb_uhci to the DEFBOOTSTR entry. Then reboot the system and you should be good to go. Note that the Dell supplied Vnd=TSSTcorp Prd=DVD+-RW TS-H653G Rev=DW10 SATA drive was not compatible with Microlite Backup Edge (errored out on DVD-R media, CDR was ok but too small). I had to pull it and install a Panasonic SW9576C PATA drive with Rosewill RC204 SATA/PATA converter (and a suitable SATA to Molex 4-pin power adapter). Enjoy. -- Steve Fabac S.M. Fabac & Associates 816/765-1670

Steve M. Fabac, Jr. wrote: > As to setting NHBUF to 130000: looked like a reasonable conclusion > based upon an outsider reading the tuning guide example and deducing > that if NHBUF can only reach 524288 (as tuned in stune) then to > insure that each processor can have its own hash table of NBUF I > need to set NBUF to 1/4 (for 4 CPUs) of the maximum derived from > the maximum value I can set for NHBUF. Tail wagging the dog here. NBUF has serious performance effects, setting it too low means you're likely to do far more disk I/O than necessary. These are multi-millisecond delays (times thousands or millions of disk accesses). Badly tuned NHBUF costs you CPU time. The tuning information in the guide is telling you how to tune it to cost the least possible CPU. It forgets that this isn't necessarily a goal, and that you're offsetting the CPU gains against memory losses. In practice, neither the CPU nor memory effects of NHBUF are likely to be important with modern systems. Worst possible tuning (NHBUF=32) might cost 10% of CPU. Crudely, each power of two costs 1/2 as much CPU, and obviously twice as much memory. Remember that 10% and 1/2 as much CPU per doubling are made-up numbers -- they're close to true but only crudely so. Anyway, let's look at a table of costs. I'll assume a 3GHz CPU so "10%" = 300MHz; table skips many powers of 2: NHBUF CPU cost Fraction of Memory cost Fraction of ====== =(MHz)== =4x2.66GHz= =(Kbytes)== == 4 GiB == 32 300.00 1/35 .25 1/16777216 64 150.00 1/71 .50 1/8388608 128 75.00 1/142 1.00 1/4194304 2048 4.69 1/2270 16.00 1/262144 32768 .29 1/36318 256.00 1/16384 524288 .02 1/581086 4096.00 1/1024 I think I care more about 300MHz than 256 bytes of memory; and more about 4MBytes than 20KHz of CPU. Where is the balance? Who knows -- on your 4x 2.66GHz, 4GiB system, the very worst of each column is 1/35th of your CPU budget, or 1/1024 of your memory budget. Maybe nobody cares at all. I still like to optimize, so I would probably choose something like 32768 NHBUF, where the fractional cost out of each department is similar, and both are vanishingly small. Important thing to notice: the fraction columns are very different on a system with one 33MHz 486 and 16MB RAM. 486 cycles are probably worth 1/3 of what yours are, so imagine it's actually 11MHz. Now with only 2048 NHBUF you're looking at over a third of your CPU! 32K NHBUF costs a still noticeable 3% of your CPU, but now it's up to 1/64 of your RAM, also approaching noticeability. If you had *two* 33MHz CPUs, the same maths would apply, except with such slow CPUs, poor cache, poor cache coherency hardware, etc., there really *was* a serious penalty for two CPUs trying to walk the same hash list. The tuning guide approximates that by pretending the CPU cost is 4x as high; this is adequate for discussion purposes. If 32K NHBUF costs 12% of your CPU or 1/64 of RAM, maybe you would rather have 64K NHBUF -- 6% of CPU and 1/32 of RAM. It becomes a delicate balancing act. You're in an age of such abundance that you don't *really* have to care about this tuning at all, you can set NHBUF to *any* of its allowed values and likely won't notice the penalties in either department. Note: "memory cost" is constant, the buffers are allocated a boot time and fixed in memory. "CPU cost" is a theoretical maximum you might hit if every CPU was running code which spent all its time reading and then ignoring (so as to get on with the next read as quickly as possible) data, all of which was resident in the buffer cache. Real applications which are not disk-hammering benchmarks will never approach that perfect storm; real world "CPU cost" is likely to be less than 1% of the theoretical. > I take it from your comments that you would recommend setting NBUF to > 450000 and setting NHBUF to 0 and let the kernel do what it wants > with the result. I would set NBUF to 450000 and think about manually setting NHBUF lower than the kernel will autotune. As I say, the costs are low in all directions; still, I resent wasting 4MiB of RAM when 256KiB will do just fine. > >> Mar 24 15:13:48 unix kernel: Hz = 100, i/o bufs = 313188k (high bufs = 312164k) > > > > Ohhhh.... are you relating NHBUF to "high bufs" here? No relation. > > "high bufs" are buffers outside the first 16MiB, the ISA DMA range. > > You'll notice that all but 1024 of yours are high, presumably by > > autotune decision. > > No, the table was only meant to show what the kernel did with auto > tuning NBUF during the stages of the installation and configuration > until I hit upon the (now discredited) decision to set NBUF to > 130000. Ok. I had just noticed the 'h' in "high bufs" and realized someone could be tricked by that. What you see in the autotuning is that (for large memory systems) NBUF is linearly related to total memory available after the rest of kernel stuff is set up. As you added and removed drivers you changed the size of the kernel itself by some few hundred KiB, which in turn affects NBUF by a few 10s of K. Basically just noise. You can also see that in order to reach the 450000 max on that calculation, system memory size would have to be much larger than the 4GiB max. > The values auto tuned for i/o bufs seemed to imply that the SMP kernel > did not follow the tuning recommendations for SMP of being able to > allocate NBUF * 2 (to next higher power of 2) to NHBUF as clearly > 313124 * 2 is already greater then the 524288 stune maximum limit. Right, it can't at that level since it would exceed the 512K hbufs max. The NBUF autotune algorithms were revisited many times over the years, as we went from a "huge system" being 16MiB to 64, 128, 512, etc. NHBUF was along for the ride without anyone seriously thinking about how it was being set ridiculously too large. > >> SMP and MP5 installed > >> Mar 24 15:52:22 unix kernel: Hz = 100, i/o bufs = 313124k (high bufs = 312100k) > > To the outside observer: either the kernel auto tuning does not > subscribe to the SMP tuning guide or it uses some other logic > to calculate NBUF and derive a usable NHBUF. As evidence we see > auto tuning setting 313188k prior to installing SMP and 313124k > imediately after installing SMP and booting with all four cores > and HT active for a count of 8 CPU's. Just noise caused by the size of the SMP kernel code. No such thing as a "useable NHBUF". With a hashed table you can talk about an *average* hash chain length, but you never know the specific max length without specifically analyzing a momentary snapshot of a live system. Hash values are effectively "random", it is always possible for a large number of hashed items to fall into a single bucket even though the average is still small. Therefore, the algorithms which deal with many-hashes-in-a-bucket *must* be 100% perfect no matter how sparse you try to make the hash. And that means that whether you tune the number of hash buckets "correctly" or not, the system will keep working. There is only a CPU cost for having to walk longer chains. I've been talking like everyone knows what a hash bucket is, but ... well, not. In my building at work, there's a mail room with maybe 30 slots for people's mail. One might be "A", "B", "Ca-Ch", "Ci-Cz", etc. One for each letter plus a few extras for popular letters. My mail goes into the "L" slot, along with a bunch of other "L" people. If one day there are a lot of deliveries for "L" people, I may have to sift through a dozen pieces to find that, as usual, I have no paper mail at work. Other days there's nothing there. The same setup could have less slots, say "A-M" and "N-Z". Then my average sifting time would be higher. But the cost of building the wooden mail slots thingie would be lower, and the mail delivery person would have an easier time sorting into the slots. Except here it differs from the computer case: in most computer hash buckets, the items inside a bucket are kept in sorted order. So now the mailman actually has a huge pain to insert new items into "A-M" in proper alphabetical order. Or the setup could have more slots. The reasonable limit in that direction is to have one slot for each person. Then *my* search time is tiny; building the setup is a lot more expensive; it's a pain to maintain as people come and go; and the mail delivery person has to laboriously poke each item into the right slot (but never has to sort the contents of any slot). The NHBUF rules described in the OSR5 tuning doc are intended to make each mail slot to have an average of 1 item in it, so that mostly nobody has to do any sorting or thinking. You can think of the SMP effect like this: each slot of the mail rack is open at both ends. Each slot belongs to at least 2 people. When I arrive, I pull everything out of my slot, sort through, keep what's mine, put the rest back. If the other guy came by at the same time, he would be standing at the other end waiting for me to put his stuff back so he can sort through it. That would amost never happen with the mail rack. Oh, once in a while, but no big deal. Similarly, current computers are so fast that they never have to "check out" the contents of a bucket for very long. There's very little chance the other guy will come along during the same couple of microseconds. So it is not worthwhile to divide the rack up into an excess number of buckets just to avoid what almost never happens. ===== I haven't brought the consequences of high NBUF into this yet... Briefly: if you have very large NBUF, a process may write that much data "to disk" very quickly. Then it all has to be hauled from the buffer cache out to the disk. OSR5 has two tunables controlling how often the cache is scanned for pending writes (BDFLUSHR) and, during a scan, what age of pending writes are scheduled to be written ASAP (NAUTOUP). The defaults are 30 and 10: every 30s, scan 450 thousand buffers and if any of them are >10s old writes, flush them out to disk *now*. Which means the disk can go from quiet to "you have to write 450 megabytes of data as fast as possible" in an instant. This can have quite a lumpy effect on performance of the rest of the system. I recommend setting BDFLUSHR to its minimum (1s). You could still have the "write 450M all at once" syndrome *if* a process manages to dirty 450M worth of buffers within a single second. Don't know if that's actually possible. More typically you will now have smaller gaggles of writes going off every second. With NAUTOUP=10, BDFLUSHR=1, now what happens is that the buffer cache always holds onto writes for 10 seconds. Every second it gets scanned and any 10s-old writes are sent out to disk. So at any moment the buffer cache is full of written data that's between 0 and 11s old, with all the 10-11s old buffers scheduled for earliest possible write. That in turn means that a power failure or panic eats the last 10-11s worth of written data. You can control that with NAUTOUP. If it's 30, a crash eats 30s worth of data. Obviously the minimum is 1 or 0 (I think you *can* get away with 0, meaning every second, *all* pending writes are scheduled out). Downsides? There are two main ones. The purpose of delaying writes is that the same disk block may be written again before it's committed to disk. Then you completely save one physical write. This has two consequent purposes, both of which are diluted by writing sooner. First there's a performance effect: by deferring the write, if the same block is written again, you saved a write. That same amount of disk I/O bandwidth could probably have been used for a read, which might increase total system throughput. Second there's a reliability and longevity effect: by not writing, you put less stress on the media. Both hard disks and flash drives have lifetimes which are, to some degree, limited by the cumulative amount of writes ever done to them. Another reliability consideration: a large gang of writes every 30s may keep the write head lit up less of the time than 30 small writes every 1s. The most vulnerable time for a hard drive to lose power is while it's writing. Small writes all the time may therefore be slightly more dangerous to your data. There are also some tertiary effects, e.g. if BDFLUSHR is 30, some hard disks may be able to go into a low-power mode for 28 out of every 30 seconds. This might matter in the datacenter (reduce total power costs & possibly size of power feed); or on a laptop (increase battery life). Mostly none of these effects are very important. But they are worth thinking about. I would set: NBUF=450000 NHBUF=32768 BDFLUSHR=1 NAUTOUP=0 # but this one bears the most thinking about BTW the CPU costs of scanning 450000 buffers every second are *far* higher than the costs of shuffling 450000 buffers through "only" 32K hash buckets. Neither is significant on modern CPUs. >Bela<

Steve M. Fabac, Jr. wrote: > It seems counter-intuitive to disable the SCO USB drivers but > the Dell BIOS must present the USB keyboard as a PS2 keyboard > to the SCO kernel allowing you to continue the installation > by entering the information during the subsequent ISL > configuration. Shunting USB keyboard & mouse to PS/2 ports, for the benefit of old OSes, was part of the initial USB design. All manufacturers have supported it from day one. There were plenty of glitches, of course, but all have *intended* to support it correctly... All BIOSes other than super-evil ones with no useful settings, have a setting to control this. It will be called "Legacy keyboard emulation" or "PS/2 keyboard supoport" or a bunch of other names, you should be able to figure it out. > ... So the first kernel built will not boot beyond the > "no root hard disk controller" message. A real catch-22. > > The only way around this is to perform a btldinstall of the > lsil and wd drivers from the btld.1.img floppy to another > 5.0.7 system. Rebuild the kernel. Copy /stand to /tmp/stand, > copy btld.1.img file to /tmp, copy the MP5 VOL's to > /tmp/mp5, copy the bnxii_4.6.0/VOL.000.000 NIC driver > from SCO to /tmp/net, then use BackupEdge to backup up a > single directory to CDR media selecting /tmp and making > the backup bootable. etc. Well, that's one way to do it. Another way: after ISL is complete, boot from the same media as you initially did, defbootstr link="lsil wd" disable=usb_ehci,usb_ohci,usb_uhci root=hd(42) Kernel loads from CD, BTLDs from USB floppy (under BIOS control). System boots up from the hard drive. Go to single user mode, acquire the needed BTLDs somehow (network, from an ISO you burned onto a CD-ROM, or whatever). Actually you shouldn't need the USB disables on this path, so probably you can get the BTLDs from the same floppy. I'm not sure since I don't understand why you have to disable them initially. In any case, the best way is probably along the lines of these two SCO TAs: http://www.sco.com/ta/126828 http://www.sco.com/ta/126839 This is akin to one of the last projects I was working on while at SCO. The TAs and ISOs aren't my actual work, which was never completed (and would have been better ;-) 126839 offers a gaggle of different BTLD CDs. The embellishments I was working on were: - combine multiple BTLDs into a single CD (note: total weight of BTLDs available is too big for a CD's 2.88MB boot floppy image, so would still require 2-3 boot images, but no one install would ever need >1) - provide each in two forms: a "preboot" image containing only the replacement boot floppy; and a "full" image, a complete newest-release OSR507 install image with the BTLD-enhanced boot floppy image (maybe not needed, see below) - each boot floppy's /etc/default/boot would have a set of appropriate boot strings like "wd", "wd+aacraid", whatever is determined to be useful; so that users don't have to type in the full gibberish strings - using /.bootrc and /cat, emit a welcome message listing the supported hardware and corresponding bootstring nicknames - use techniques similar to the "wd" BTLD series in order to suck the BTLD off the boot media onto the hard disk link kit, so that users don't have to loop back through the second reboot-and-defboostr cycle - ultimately, provide a utility which takes a set of input BTLDs and an OSR5 boot CD, munges it all together into a single burnable, bootable ISO image that does all of the above. Advantage: allows people in the field to roll their own unique BTLD combos or install kits for newer drivers not yet done by SCO. Circumvents possible IP angst by OEM driver vendors (I heard at one point that the multi-BTLD CD couldn't be done because OEMs were against being on the same media as each other -- nevermind that all live together on the main install ISO and on the various BTLD floppy images). Note that 100% of this is work that could be done by someone outside of SCO, with no internal knowledge or source code. You would have to do a small amount of "reverse engineering", i.e. shell script reading, of the "wd" BTLD. Examining the TA 126839 ISOs would probably also be instructive. Going the utility route (last bullet point above) means you could offer this to random SCO users, for use with random BTLDs you've never seen before, all without impairing anyone's IP aspirations. Possibly a good project for the BackupEDGE or Lone-Tar people, if they still have enough of a foot in the SCO OSR5 market. >Bela<

Bela Lubkin wrote: > Steve M. Fabac, Jr. wrote: > >> It seems counter-intuitive to disable the SCO USB drivers but >> the Dell BIOS must present the USB keyboard as a PS2 keyboard >> to the SCO kernel allowing you to continue the installation >> by entering the information during the subsequent ISL >> configuration. > > Shunting USB keyboard & mouse to PS/2 ports, for the benefit of old > OSes, was part of the initial USB design. All manufacturers have > supported it from day one. There were plenty of glitches, of course, > but all have *intended* to support it correctly... > > All BIOSes other than super-evil ones with no useful settings, have a > setting to control this. It will be called "Legacy keyboard emulation" > or "PS/2 keyboard supoport" or a bunch of other names, you should be > able to figure it out. The Dell T310 BIOS only has following options for keyboard settings: Keyboard numlock On/Off Report Keyboard error Report/Do Not Report F1/F2 Prompt on error Enable/Disable > >> ... So the first kernel built will not boot beyond the >> "no root hard disk controller" message. A real catch-22. >> >> The only way around this is to perform a btldinstall of the >> lsil and wd drivers from the btld.1.img floppy to another >> 5.0.7 system. Rebuild the kernel. Copy /stand to /tmp/stand, >> copy btld.1.img file to /tmp, copy the MP5 VOL's to >> /tmp/mp5, copy the bnxii_4.6.0/VOL.000.000 NIC driver >> from SCO to /tmp/net, then use BackupEdge to backup up a >> single directory to CDR media selecting /tmp and making >> the backup bootable. > > etc. Well, that's one way to do it. > > Another way: after ISL is complete, boot from the same media as you > initially did, > > defbootstr link="lsil wd" disable=usb_ehci,usb_ohci,usb_uhci root=hd(42) I tested the above and it works on the T310. For this test, I booted the 507 July 2005 recut CD with the btld.1.img floppy in the external floppy drive. I entered maintenance mode and mounted the OSR507_SubCD_BTLD.iso from the DVD drive and used marry to add the /mnt/images/btld.1.img image on /mnt1 (created /mnt1 for the mount as /mnt was busy with the cd, could have copied /mnt/images/btld.1.img to /tmp, unmounted the cd and run marry -a /tmp/btld.1.img and then mounted the image on /mnt). I had never had occasion in the past to boot from cd or floppy media and root from the hard drive so this solution did not come to mind. Now that I have, maybe I'll remember it the next time (if there is a next time). > > Kernel loads from CD, BTLDs from USB floppy (under BIOS control). > System boots up from the hard drive. Go to single user mode, acquire > the needed BTLDs somehow (network, from an ISO you burned onto a CD-ROM, > or whatever). Actually you shouldn't need the USB disables on this > path, so probably you can get the BTLDs from the same floppy. I'm not > sure since I don't understand why you have to disable them initially. Trying defbootstr link="lsil wd" root=hd(42) gets to: Type control-d to proceed with normal start up %Sdsk-add - - - type=S ha=0 id=0 lun=0 bus=0 ht=usb_msto unit=1 %floppy - - - type=S ha=0 id=0 lun=0 bus=0 ht=usb_msto unit=0 (or type the give root password for system maintenance): and keyboard is locked up, num-lock led turns off, num-lock & caps-lock key press unresponsive. Only escape is power off. This follows my experience that without either adding the disable=usb_uhci,usb_ohci,usb_ehci directive to the /etc/default/boot DEFBOOTSTR parameter or setting sdevice.d/usb_*hci files to "N" and relinking the kernel, the T310 will not boot. This machine will never access external USB hard drives or anything other then the USB keyboard. > > In any case, the best way is probably along the lines of these two SCO > TAs: > > http://www.sco.com/ta/126828 > http://www.sco.com/ta/126839 > > This is akin to one of the last projects I was working on while at SCO. > The TAs and ISOs aren't my actual work, which was never completed (and > would have been better ;-) > > 126839 offers a gaggle of different BTLD CDs. The embellishments I was > working on were: > > - combine multiple BTLDs into a single CD (note: total weight of BTLDs > available is too big for a CD's 2.88MB boot floppy image, so would > still require 2-3 boot images, but no one install would ever need >1) > > - provide each in two forms: a "preboot" image containing only the > replacement boot floppy; and a "full" image, a complete newest-release > OSR507 install image with the BTLD-enhanced boot floppy image (maybe > not needed, see below) > > - each boot floppy's /etc/default/boot would have a set of appropriate > boot strings like "wd", "wd+aacraid", whatever is determined to be > useful; so that users don't have to type in the full gibberish strings > > - using /.bootrc and /cat, emit a welcome message listing the supported > hardware and corresponding bootstring nicknames > > - use techniques similar to the "wd" BTLD series in order to suck the > BTLD off the boot media onto the hard disk link kit, so that users > don't have to loop back through the second reboot-and-defboostr cycle > > - ultimately, provide a utility which takes a set of input BTLDs and an > OSR5 boot CD, munges it all together into a single burnable, bootable > ISO image that does all of the above. Advantage: allows people in the > field to roll their own unique BTLD combos or install kits for newer > drivers not yet done by SCO. Circumvents possible IP angst by OEM > driver vendors (I heard at one point that the multi-BTLD CD couldn't > be done because OEMs were against being on the same media as each > other -- nevermind that all live together on the main install ISO and > on the various BTLD floppy images). > > Note that 100% of this is work that could be done by someone outside of > SCO, with no internal knowledge or source code. You would have to do a > small amount of "reverse engineering", i.e. shell script reading, of the > "wd" BTLD. Examining the TA 126839 ISOs would probably also be > instructive. Going the utility route (last bullet point above) means > you could offer this to random SCO users, for use with random BTLDs > you've never seen before, all without impairing anyone's IP aspirations. > > Possibly a good project for the BackupEDGE or Lone-Tar people, if they > still have enough of a foot in the SCO OSR5 market. > >> Bela< > > -- Steve Fabac S.M. Fabac & Associates 816/765-1670

On 4/2/2011 2:50 PM, Steve M. Fabac, Jr. wrote: > Bela Lubkin wrote: >> Steve M. Fabac, Jr. wrote: >> >>> It seems counter-intuitive to disable the SCO USB drivers but >>> the Dell BIOS must present the USB keyboard as a PS2 keyboard >>> to the SCO kernel allowing you to continue the installation >>> by entering the information during the subsequent ISL >>> configuration. >> >> Shunting USB keyboard & mouse to PS/2 ports, for the benefit of old >> OSes, was part of the initial USB design. All manufacturers have >> supported it from day one. There were plenty of glitches, of course, >> but all have *intended* to support it correctly... >> >> All BIOSes other than super-evil ones with no useful settings, have a >> setting to control this. It will be called "Legacy keyboard emulation" >> or "PS/2 keyboard supoport" or a bunch of other names, you should be >> able to figure it out. > > > The Dell T310 BIOS only has following options for keyboard settings: > > Keyboard numlock On/Off > Report Keyboard error Report/Do Not Report > F1/F2 Prompt on error Enable/Disable Those are just the main menu options. The setting he's talking about is almost never there. Don't limit yourself to looking for keyboard settings. Settings that can affect this can be almost anywhere. Usually in some other screen pertaining to enabling/disabling i/o devices is some usb settings. You have to look through every option on every screen because there is no standard to the way the bios settings are organized or labeled in different machines. One screen may have an option that enables/disables the use of the usb hardware at all, while one or more entirely other screen may have options that affect how the usb hardware is used, and may or may not even appear on the screen unless usb is enabled on that other screen, and may or may not appear until after a reboot if usb had been disabled originally. I had one where you could enable usb and clearly enable legacy hardware via usb, aka booting from usb floppy. This machine also had a standard floppy controller and a bios option to disable the floppy controller, which was on a completely different screen from the main screen where you could say what type of drive was drive A: including "None". Only by trial and error did I figure out that if you had no standard floppy drive installed, and wanted to boot from a usb floppy, you had to not only enable usb and enable legacy floppy on usb, you also had to leave the floppy controller enabled, although you could specify None for drive A: on the main screen. Those options were all in different places, plus since this has to do with booting there was also the boot devices and boot order options on yet other screens. The point is you can't just look for "keyboard" and think you found all the settings that affect the keyboard. All that said, I know Dells can have very limited bios settings with only one or two screens of options so I know it is possible there really are no other options that you can look at that might affect this. But the above doesn't prove it, because those are very common options to see on the default main screen of many bios's which have the settings he's talking about elsewhere and never on that main screen. -- bkw

Brian K. White wrote: > On 4/2/2011 2:50 PM, Steve M. Fabac, Jr. wrote: >> Bela Lubkin wrote: >>> Steve M. Fabac, Jr. wrote: >>> >>>> It seems counter-intuitive to disable the SCO USB drivers but >>>> the Dell BIOS must present the USB keyboard as a PS2 keyboard >>>> to the SCO kernel allowing you to continue the installation >>>> by entering the information during the subsequent ISL >>>> configuration. >>> >>> Shunting USB keyboard & mouse to PS/2 ports, for the benefit of old >>> OSes, was part of the initial USB design. All manufacturers have >>> supported it from day one. There were plenty of glitches, of course, >>> but all have *intended* to support it correctly... >>> >>> All BIOSes other than super-evil ones with no useful settings, have a >>> setting to control this. It will be called "Legacy keyboard emulation" >>> or "PS/2 keyboard supoport" or a bunch of other names, you should be >>> able to figure it out. >> >> >> The Dell T310 BIOS only has following options for keyboard settings: >> >> Keyboard numlock On/Off >> Report Keyboard error Report/Do Not Report >> F1/F2 Prompt on error Enable/Disable > > Those are just the main menu options. > The setting he's talking about is almost never there. > > Don't limit yourself to looking for keyboard settings. Settings that can > affect this can be almost anywhere. Usually in some other screen > pertaining to enabling/disabling i/o devices is some usb settings. > > You have to look through every option on every screen because there is > no standard to the way the bios settings are organized or labeled in > different machines. > > One screen may have an option that enables/disables the use of the usb > hardware at all, while one or more entirely other screen may have > options that affect how the usb hardware is used, and may or may not > even appear on the screen unless usb is enabled on that other screen, > and may or may not appear until after a reboot if usb had been disabled > originally. > > I had one where you could enable usb and clearly enable legacy hardware > via usb, aka booting from usb floppy. This machine also had a standard > floppy controller and a bios option to disable the floppy controller, > which was on a completely different screen from the main screen where > you could say what type of drive was drive A: including "None". > Only by trial and error did I figure out that if you had no standard > floppy drive installed, and wanted to boot from a usb floppy, you had to > not only enable usb and enable legacy floppy on usb, you also had to > leave the floppy controller enabled, although you could specify None for > drive A: on the main screen. Those options were all in different places, > plus since this has to do with booting there was also the boot devices > and boot order options on yet other screens. > > The point is you can't just look for "keyboard" and think you found all > the settings that affect the keyboard. > > All that said, I know Dells can have very limited bios settings with > only one or two screens of options so I know it is possible there really > are no other options that you can look at that might affect this. But > the above doesn't prove it, because those are very common options to see > on the default main screen of many bios's which have the settings he's > talking about elsewhere and never on that main screen. > Brian, You are right about the Dell T310 having a limited BIOS setting. The keyboard settings are the only mention of keyboard in any of the BIOS screens. Unless there is some secret key combination to enable "advanced" settings (�la the old Compaq BIOS), the only settings for USB is under the "Integrated Devices" selection: User accessible ports: All Ports on / Only back ports on / All ports off Internal USB port: On / Off and "PCI IRQ Assignments": Where you can set "integrated USB EHCI controller 1" and "integrated USB EHCI controller 2" to what ever IRQ you desire. There is no "legacy" mode setting for USB. SCO 5.0.7 seems perfectly happy to function with the "disable=usb_uhci,usb_ehci,usb_ohci" bootstring. The USB keyboard continues to work and may be unplugged and replugged without problems. The system can be booted without the USB keyboard attached and subsequently plugging in the keyboard works with the console screens. -- Steve Fabac S.M. Fabac & Associates 816/765-1670

Steve M. Fabac, Jr. wrote: > There is no "legacy" mode setting for USB. SCO 5.0.7 seems perfectly > happy to function with the "disable=usb_uhci,usb_ehci,usb_ohci" > bootstring. The USB keyboard continues to work and may be unplugged > and replugged without problems. The system can be booted without the > USB keyboard attached and subsequently plugging in the keyboard > works with the console screens. BIOS (via SMI) is receiving USB keyboard inputs and emulating a PS/2 keyboard. PS/2 keyboards have no software procotol for dealing with keyboards appearing and disappearing; in fact you're really not supposed to ever plug one in/out while powered on. So the easiest route for BIOS is to pretend that a PS/2 keyboard is always present -- it just doesn't happen to get anything typed on it while no USB keyboard is present to generate inputs. They could have chosen to do something stupid when booted with no USB keyboard. Fortunately, in this case it would actually be more work to mis-implement than to get it right... >Bela<

Similiar Articles:

Strange df and du behavior - comp.unix.solaris
... Can someone explain strange behavior of "df" and "du" commands I ... Kernel version: SunOS 5.10 Generic_137111-01 What is strange about that output? ... (0.169 seconds) Tweet

strange output of date command with TZ variable - comp.sys.hp.hpux ...
1 Replies 181 Views (0.025 seconds) Tweet ... strange output of date command with TZ variable - comp.sys.hp.hpux ... Hi, I am running date command ...

Weird RMAN error - comp.databases.oracle.server
I am Oracle 11.1.0.7.1, My rman catalog is ... Show quoted text - > > Here is the output in rman log file. THis command works most of the > time, once in a while Weird ...

XVR-100 console output - comp.unix.solaris
... request: 42 Current serial number in output stream: 50 rdekstop 1.3.0 ... sounds like the usual Trident/ATI-driver hw ... 7/5/2012 6:53:17 PM

FC devices disappear after patching Solaris 9? - comp.unix.solaris ...
Something strange is going on. I've now got *two* separate ... installed the latest Solaris 9 on the machines (HW 0803 ... WWPN 21:00:00:03:39:00:0c:d2 to FCP/SCSI Target 0 ...

Way to limit xtics in histogram - comp.graphics.apps.gnuplot ...
... should be evident from this command: everyfifth(col) = (int(column(col) % 5 == 0) ? ... col) = (int(column(col)) % 5 == 0 ... output exit And the final output ...

How much memory do I have? - comp.unix.solaris
... 0 none U0701 128 OK ... according to your output... ....output looks real strange by ... bugged, check for patches > 3) your hw is broken, fix... The output ...

[NEWBIE]Strange problem: I can see through objects! - comp ...
... gluNewQuadric(); glColorf(1.0f,0.0f,0.0f ... the whole scene with a glRotate preceding the command ... perfect object ... in some "part" that give a strange rendering output ...

change box colors in bar graph - comp.graphics.apps.gnuplot ...
Is there any way to control the color of ... w boxerrorbars notitle fs solid .5 lt 1 lw > 1 lc rgb 'cyan' > set output Weird. ... 9656.4 97.1 1.0 > "QC-low" 40.0 3.0 7.5 ...

Performance comparison Solaris 8 versus Solaris 9 - comp.unix ...
The HW (Ultra 1 170E, 256 MB of RAM, and 9 GB 7200 ... 8 Replies 129 Views (0.103 seconds) Tweet ... In solaris 10 the output of command SAR (%WIO) or IOSTAT (CPU: wt ...

INIT: Command is respawning too rapidly - comp.sys.hp.hpux ...
... problem as you can read in the subject: the init command is ... etc/inittab |grep -v -e ^# -e console Check ps output for ... hp.hpux ..... init fails when the pshared arg isn't 0 ...

Configuration register strangeness - comp.dcom.sys.cisco ...
2 Replies 115 Views (0.073 seconds) Tweet ... Weird output from ntpq -p - comp.protocols.time.ntp ... No tftpdnld command - comp.dcom.sys.cisco... set/show ...

External command return codes - comp.lang.rexx
... get from the ssh command is 0 no ... External command return codes - comp.lang.rexx I keep getting a weird return code. ... so can be get the output from a system command ...

Giant packets on a 10Gig interface - comp.dcom.sys.cisco ...
... 10/100/1000mb RJ45 WS-X6516-GE-TX Mod Hw ... 12.2(17a)SX1 3 1.1 6.3(1) 8.2(0.56)TET 5 3.1 7 ... 10Gb/s input flow-control is off, output flow-control is ...

Fixed length records containing 2 different records types with ...
... 0 0 0 I get a 0 in the output file for every record in the input file. Strange. ... This command line awk "\"A\"==substr($0,18,1)" data produces this output, using any of ...

Windows PowerShell - Wikipedia, the free encyclopedia
... to compose complex commands, allowing the output of one command ... PS> 'hello, world!'.ToUpper() Insert the string 'ABC ... 5.0.1: 293: No: Yes: Internet Information Services: 7.0: 54

Audacity Reference
If the output meter clips then you need to make some or all of your ... In the figure above, there are five control points, at 1.0, 3.0, 5.0, 7.0, and 9.0 seconds.

7/25/2012 6:43:57 PM