Re: RH9 mouse cursors
On Sunday 05 October 2003 08:15, Jim Hayward wrote: > On Sat, 2003-10-04 at 09:11, NiteOwl wrote: > > Anyone knows how to get rid of those annoying color mouse cursors in RH9? > > I need the old, plain, default, non-flashing, vanilla X11R6 cursors, > > please!!! > > Well, if you "really" don't want the new cursors... > > Create the file ( if you don't already have it ) ~/.Xresources and place > in it: Xcursor.core yes It works perfectly (I set the value system-wide putting it in /etc/X11/Xresources)! Thanks a lot! --Tony -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
RH9 mouse cursors
Hello. Anyone knows how to get rid of those annoying color mouse cursors in RH9? I need the old, plain, default, non-flashing, vanilla X11R6 cursors, please!!! ;'( Thanks! --NiteOwl -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Re: Random CPU initialization on Athlon SMP
On Saturday 13 September 2003 15:24, Leonard den Ottolander wrote: > > Have you tried swapping the cpu's? Not sure if the 2 cpu's should be > > identical. See the MB docs for that. No, I haven't tried it... But I don't think this could be a problem, except in case of some weird bug somewhere (BIOS or kernel). > When googling for this I find references that at least for Pentium's the > stepping of cpu's in dual processor boards must be identical in most cases. > Guess that might be your problem indeed. Athlons are different from Pentiums: you can mix up every stepping, the only requirement is (should be) that CPU speed must be the same on both CPUs. --Tony -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
Random CPU initialization on Athlon SMP
Hello all. I have a very strange problem on my dual Athlon MP system since CPU initialization seems to be performed in a random way. In about 50% of bootstraps the kernel manages to correctly enable the second CPU, in the other 50% not. In the former case the system is rock solid, in the latter the system uses only one CPU and is very unstable. My system is made up of: 2 Athlon MPs 2200 (different steppings, 0 and 1) Gigabyte GA-7DPXDW-P motherboard (AMD760MPX chipset) 512 MiB PC2100 DDR ECC DIMM (by Corsair) The O.S. is a "vanilla" RedHat 9 with the latest Athlon SMP kernel. Attached to this email are 2 dmesg, referring on the 2 cases. Thanks for your help. --Tony Linux version 2.4.20-20.9smp ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 SMP Mon Aug 18 11:18:01 EDT 2003 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: fec0 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. found SMP MP-table at 000f4d60 hm, page 000f4000 reserved twice. hm, page 000f5000 reserved twice. hm, page 000f reserved twice. hm, page 000f1000 reserved twice. On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 17 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Kernel command line: ro root=LABEL=/ hda=ide-scsi ide_setup: hda=ide-scsi Initializing CPU#0 Detected 1800.113 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 3591.37 BogoMIPS Memory: 510672k/524224k available (1458k kernel code, 10988k reserved, 1075k data, 156k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode cache hash table entries: 32768 (order: 6, 262144 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1cbfbff CPU: Common caps: 0383fbff c1cbfbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0383fbff c1cbfbff CPU: Common caps: 0383fbff c1cbfbff CPU0: AMD Athlon(tm) MP 2200+ stepping 00 per-CPU timeslice cutoff: 731.09 usecs. task migration cache decay timeout: 10 msecs. enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: Booting processor 1/1 eip 2000 Not responding. Error: only one processor found. ENABLING IO-APIC IRQs Setting 2 in the phys_id_present_map ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-5, 2-6, 2-11, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=0 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... . (found pin 0) ... failed. ...trying to set up timer as Virtual Wire IRQ... failed. ...trying to set up timer as ExtINT IRQ... works. number of MP IRQ sources: 19. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00170011 ... : max redirection entries: 0017 ... : PRQ implemented: 0 ... : IO APIC version: 0011 register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 0FF 0F 000 0 01139 02 000 00 100 0 00000 03 0FF 0F 000 0 01141 04 0FF 0F 000 0 01149 05 000 00 100 0 00000 06 000 00 100 0 00000 07 0F
Re: Strange hard disk problem.
On Tuesday 20 August 2002 21:28, Sam Ockman wrote: > I'm not really familiar with the problem, but you can absolutely > slow down the halting procedure. > > It's simplay a bash file found at /etc/rc.d/init.d/halt...so go > ahead and add more sleep commands (or increase the time of sleeps > already found in it)... The last line of the halt *script* is: eval $command $HALTARGS where, in case of a "proper" halt we have that command=halt and HALTARGS are the options for the halt command. So adding some sleep command in the script cannot help since the responsible of putting harddrives in standby mode before poweroff is the halt *command*... The "problem" should be in the halt *command* and not in the script... Before modifing the /sbin/halt source code (!) I need some confirmation that my "problem" is somewhat real and not the result of my natural paranoia... ;) What do you think? Thanks --Tony -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
Strange hard disk problem.
Hello all. I have a strange problem with RH7.3 and my hard disks: When I power-off the system hard disks emit a strange sound (It seems like some kind of "brake" is in action =:/ ): I think this is the same sound that was hearable on some HDs on old AT systems, when powered off. I recently swapped my old Gigabyte motherboard with a new, practically identical, Soltek one to avoid some minor glitches affecting the former. I left unchanged my old RH7.3 installation as well as all the HW setup I had with the old motherboard. The system works perfectly... Except the strange sound. ;( When I shutdown the PC all HDs are turned off before powering down the system, this worked perfectly with the old motherboard as the disks emitted no sound when powered off, but this does not occur with the new one. I think that the halt procedure is run "too fast" with the new motherboard. HDs are not powered off properly before the motherboard turns off, so this hardware "brake" is started by hard disks thus emitting the strange sound: I tried to halt the system without powering off the motherboard. The hard disks are powerd off properly and emit no sound at all. Than I can power off the PC manually and all goes well. What do you think of this "problem"? Is my diagnose correct? If I am right, is there a way to slow down the halting procedure just a bit, to permit HDs to shutdown properly? regards, --Tony -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
