* Re: [LARTC] Neighbour table overflow
From: Petru Paler @ 2002-12-07 9:35 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103923568826933@msgid-missing>
On Sat, Dec 07, 2002 at 09:59:17AM +0530, Arindam Haldar wrote:
> what causes this to happen ?... what is the size of neigh tables? ..can
> we increase the default size of neighbour table ?
Is the loopback interface up and configured?
Petru
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [PATCH 2.4.20] Via 8233 Sound Support
From: Nathaniel Russell @ 2002-12-07 9:38 UTC (permalink / raw)
To: reddog83; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 305 bytes --]
This patch adds support for the Via8233 Onboard Sound Card.
This patch applies to Linux Kernel 2.4.20 cleanly.
The only file this patch touch's is drivers/sound/via82cxxx_audio.c
Please apply to current Linux Kernel 2.4.x
Nathaniel
Please CC me as I'm not subscribed to the list
reddog83@chartermi.net
[-- Attachment #2: Via 8233 Sound Support --]
[-- Type: TEXT/PLAIN, Size: 762 bytes --]
diff -urN linux-sound/drivers/sound/via82cxxx_audio.c linux/drivers/sound/via82cxxx_audio.c
--- linux-sound/drivers/sound/via82cxxx_audio.c 2002-08-02 20:39:44.000000000 -0400
+++ linux/drivers/sound/via82cxxx_audio.c 2002-12-07 04:28:04.000000000 -0500
@@ -40,7 +40,6 @@
#include "dev_table.h"
#include "mpu401.h"
-
#undef VIA_DEBUG /* define to enable debugging output and checks */
#ifdef VIA_DEBUG
/* note: prints function name for you */
@@ -354,6 +353,8 @@
static struct pci_device_id via_pci_tbl[] __initdata = {
{ PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
PCI_ANY_ID, PCI_ANY_ID, },
+ { PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_5,
+ PCI_ANY_ID, PCI_ANY_ID, },
{ 0, }
};
MODULE_DEVICE_TABLE(pci,via_pci_tbl);
^ permalink raw reply
* tar for "full" floppy backup?
From: Jerry James Haumberger @ 2002-12-07 9:24 UTC (permalink / raw)
To: linux-newbie
Hello everyone --
Thank you for offering me various suggestions on how to possibly
get tar to make a backup archive on multiple floppies. Sorry to
say, none of the suggestions worked.
The only result was that tar would make an archive in whatever
directory I happened to be in when creating the archive -- and
it would ignore the /dev/fd0 device.
When I used the "M" option, nothing occurred. When I tried
adding the "z" option, I was told that multiple compressed archives
were not possible.
When I try to use the Slackware manual command (SAMS), it messes
up the floppy -- which has to be reformatted and so on.
The question remains: How can I back up -- with tar or any other
Slackware 3.5 program -- my 9 MBs of files from the BasicLinux
console with multiple floppies? And in compressed format?
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* MSR__EE flag cause problem
From: Liu Fred-a18596 @ 2002-12-07 9:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi, Greetings,
I am porting PPCBoot-1.1.5 to a PPC852 board. When PPCboot executes this
statement
set_msr(get_msr() | MSR_EE);
in "interrupt_init()" which located at "cpu/mpc8xx/interrupts.c", the
console will display random characters.
But if I get rid of MSR_EE, that is "set_msr(get_msr());", then PPCBoot will
go on and display prompt.
I am a newbie for 8xx. What should I do?
BR,
Fred
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH 2.4.20] Via AGP 8633
From: Nathaniel Russell @ 2002-12-07 9:19 UTC (permalink / raw)
To: reddog83; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212070413510.5667-200000@reddog.example.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 462 bytes --]
Oh i forgot to also attch my dmesg for proof.
On Sat, 7 Dec 2002, Nathaniel Russell wrote:
> This patch add's support for the Via 8633 AGP Card it is diffed against
> Linux Kernel-2.4.20 and most likely applies to current 2.5.x series
> kernel.
> Please Apply.
>
> Nathaniel
>
> PS. Thank you Dave for pointing me in the right direction, it just alittle
> common sense and it works.
>
> Please CC me as I'm not subsribed to the list
> reddog83@chartermi.net
>
[-- Attachment #2: dmesg --]
[-- Type: TEXT/PLAIN, Size: 9572 bytes --]
Linux version 2.4.20 (root@reddog) (gcc version 3.2.1) #1 Fri Dec 6 01:28:57 EST 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000007ff0000 (usable)
BIOS-e820: 0000000007ff0000 - 0000000007ff3000 (ACPI NVS)
BIOS-e820: 0000000007ff3000 - 0000000008000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB LOWMEM available.
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux ro root=301
Initializing CPU#0
Detected 648.910 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1294.33 BogoMIPS
Memory: 126332k/131008k available (1730k kernel code, 4288k reserved, 623k data, 104k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: After generic, caps: 008031b5 808030b5 00000000 00000000
CPU: Common caps: 008031b5 808030b5 00000000 00000000
CPU: Centaur VIA Samuel stepping 03
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/3074] at 00:11.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
VFS: Diskquotas version dquot_6.4.0 initialized
Journalled Block Device driver loaded
ACPI: Core Subsystem version [20011018]
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S1 S4 S5
Processor[0]: C0 C1 C2, 2 throttling states
ACPI: Power Button (FF) found
ACPI: Multiple power buttons detected, ignoring fixed-feature
ACPI: Power Button (CM) found
ACPI: Sleep Button (CM) found
ACPI: Thermal Zone found
pty: 512 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10e
smapi::smapi_init, ERROR invalid usSmapiID
mwave: tp3780i::tp3780I_InitializeBoardData: Error: SMAPI is not available on this machine
mwave: mwavedd::mwave_init: Error: Failed to initialize board data
mwave: mwavedd::mwave_init: Error: Failed to initialize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD400BB-53DEA0, ATA DISK drive
hdc: Pioneer DVD-ROM ATAPIModel DVD-106S 012, ATAPI CD/DVD-ROM drive
hdd: PCRW804, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c0396ea4, I/O limit 4095Mb (mask 0xffffffff)
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(100)
ide-floppy driver 0.99.newide
Partition check:
hda: hda1 hda2 hda3 hda4
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 7777K size 1024 blocksize
loop: loaded (max 8 devices)
ide-floppy driver 0.99.newide
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: PIONEER Model: DVD-ROM DVD-106 Rev: 1.22
Type: CD-ROM ANSI SCSI revision: 02
Vendor: PHILIPS Model: PCRW804 Rev: 2,1
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi0, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
sr1: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs : 511.600 MB/sec
32regs : 285.600 MB/sec
pII_mmx : 557.600 MB/sec
p5_mmx : 595.200 MB/sec
raid5: using function: p5_mmx (595.200 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
LVM version 1.0.5+(22/07/2002)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 104k freed
Adding Swap: 1714600k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
reiserfs: checking transaction log (device 03:02) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
rivafb: RIVA MTRR set to ON
Console: switching to colour frame buffer device 80x30
rivafb: PCI nVidia NV4 framebuffer ver 0.9.3 (RIVA-VTNT2, 8MB @ 0xE4000000)
Via 686a audio driver 1.9.1
PCI: Found IRQ 11 for device 00:11.5
PCI: Sharing IRQ 11 with 00:0a.0
ac97_codec: AC97 Audio codec, id: ICE17(ICE1232)
via82cxxx: board #1 at 0xE800, IRQ 11
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 11 for device 00:11.2
PCI: Sharing IRQ 11 with 00:0a.1
PCI: Sharing IRQ 11 with 00:11.3
PCI: Sharing IRQ 11 with 00:11.4
uhci.c: USB UHCI at I/O 0xdc00, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 11 for device 00:11.3
PCI: Sharing IRQ 11 with 00:0a.1
PCI: Sharing IRQ 11 with 00:11.2
PCI: Sharing IRQ 11 with 00:11.4
uhci.c: USB UHCI at I/O 0xe000, IRQ 11
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 11 for device 00:11.4
PCI: Sharing IRQ 11 with 00:0a.1
PCI: Sharing IRQ 11 with 00:11.2
PCI: Sharing IRQ 11 with 00:11.3
uhci.c: USB UHCI at I/O 0xe400, IRQ 11
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 11 for device 00:0a.2
PCI: Sharing IRQ 11 with 00:08.0
hcd.c: ehci-hcd @ 00:0a.2, NEC Corporation USB 2.0
hcd.c: irq 11, pci mem ca1c4000
usb.c: new USB bus registered, assigned bus number 4
ehci-hcd.c: USB 2.0 support enabled, EHCI rev 0.95
hub.c: USB hub found
hub.c: 5 ports detected
PCI: Found IRQ 11 for device 00:0a.0
PCI: Sharing IRQ 11 with 00:11.5
usb-ohci.c: USB OHCI at membase 0xca1cc000, IRQ 11
usb-ohci.c: usb-00:0a.0, NEC Corporation USB
usb.c: new USB bus registered, assigned bus number 5
hub.c: USB hub found
hub.c: 3 ports detected
PCI: Found IRQ 11 for device 00:0a.1
PCI: Sharing IRQ 11 with 00:11.2
PCI: Sharing IRQ 11 with 00:11.3
PCI: Sharing IRQ 11 with 00:11.4
usb-ohci.c: USB OHCI at membase 0xca1ce000, IRQ 11
usb-ohci.c: usb-00:0a.1, NEC Corporation USB (#2)
usb.c: new USB bus registered, assigned bus number 6
hub.c: USB hub found
hub.c: 2 ports detected
8139too Fast Ethernet driver 0.9.26
PCI: Found IRQ 11 for device 00:09.0
eth0: D-Link DFE-538TX (RealTek RTL8139) at 0xca1d7000, 00:50:ba:c8:1c:12, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139C'
es1370: version v0.37 time 03:23:54 Dec 6 2002
PCI: Found IRQ 11 for device 00:08.0
PCI: Sharing IRQ 11 with 00:0a.2
es1370: found adapter at io 0xd000 irq 11
es1370: features: joystick off, line in, mic impedance 0
usb-uhci.c: $Revision: 1.275 $ time 03:27:43 Dec 6 2002
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 41e1.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 94M
agpgart: Unsupported Via chipset (device id: 3091), you might want to try agp_try_unsupported=1.
agpgart: no supported devices found.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 94M
agpgart: Unsupported Via chipset (device id: 3091), you might want to try agp_try_unsupported=1.
agpgart: no supported devices found.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 94M
agpgart: Detected Via 8633 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
^ permalink raw reply
* [PATCH 2.4.20] Via AGP 8633
From: Nathaniel Russell @ 2002-12-07 9:18 UTC (permalink / raw)
To: reddog83; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 346 bytes --]
This patch add's support for the Via 8633 AGP Card it is diffed against
Linux Kernel-2.4.20 and most likely applies to current 2.5.x series
kernel.
Please Apply.
Nathaniel
PS. Thank you Dave for pointing me in the right direction, it just alittle
common sense and it works.
Please CC me as I'm not subsribed to the list
reddog83@chartermi.net
[-- Attachment #2: Via 8633 AGP --]
[-- Type: TEXT/PLAIN, Size: 497 bytes --]
diff -urN linux-agp/drivers/char/agp/agpgart_be.c~ linux/drivers/char/agp/agpgart_be.c
--- linux-agp/drivers/char/agp/agpgart_be.c 2002-12-02 19:20:22.000000000 -0500
+++ linux/drivers/char/agp/agpgart_be.c 2002-12-07 04:09:59.000000000 -0500
@@ -4714,6 +4714,12 @@
"Via",
"Apollo Pro KT266",
via_generic_setup },
+ { PCI_DEVICE_ID_VIA_8633_0,
+ PCI_VENDOR_ID_VIA,
+ VIA_GENERIC,
+ "Via",
+ "8633",
+ via_generic_setup },
{ 0,
PCI_VENDOR_ID_VIA,
VIA_GENERIC,
^ permalink raw reply
* I think it's now time for the diald-1.01 release!
From: Duncan Haldane @ 2002-12-07 8:28 UTC (permalink / raw)
To: linux-diald, Mike Jagdis, Per Jessen
[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]
Hi,
I'm a long-time diald user, and I since the modern linux kernels
are declaring that ethertap is obsolete, tun is the thing, I finally
made a new, this time successful, attempt to get diald+tun working.
(I failed in January). I used the diald-1.01 cvs branch, not diald-2.0 cvs.
A few tweeks were needed, but now it works.
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/diald login
(just press return when the CVA password is asked for)
then:
cvs -d:pserver:anonymous@cvs.diald.sourceforge.net:/cvsroot/diald \
co -r DIALD1_0 diald (all on one line)
will get the diald-1.01 cvs source instead of the 2.0 version (work in
progress)..
Here are three patches for small fixes.
diald-1.01-tundoc.patch (a) adds an entry for HAVE_LINUX_IF_TUN_H to
config.h.in (This was a real GOTCHA for
building diald with tun support till I
found the problem....)
(b) Adds a README.tun doc (also needed :) )
diald-1.01-void.patch silences a compiler warning: functions refered
to by pointers need void arguments....
(del_impulse, del_connection in firewall.c)
diald-1.01-utils.patch slight revision of Per Jenssen's patch for using
netdb to parse the /etc/sevices file. I added
a test for netdb.h in configure.in (and hence in
configure after running autoconf), and an entry
USE_NETDB in config.h.in that controls use of netdb
rather than the home-made parser, and is switched off
if netdb.h is missing. I let USE_NETDB be true by
default if netdb.h is found. (Is there ever
some reason to not use netdb even if netdb.h is
found ???)
The bzipped patches are attached.
Jaggy, It would be a good idea to get a diald-1.01 release done now, as its
been a long time since 1.0.
If you are too busy, I can help: I administer two sourceforge projects
that I somehow inherited, and keep ticking over, so I have lots of
experience at sourceforge releases.
.
----------------------------------
E-Mail: Duncan Haldane <duncan_haldane@users.sourceforge.net>
Date: 07-Dec-2002
Time: 02:44:07
This message was sent by XFMail
----------------------------------
[-- Attachment #2: diald-1.01-void.patch.bz2 --]
[-- Type: application/octet-stream, Size: 715 bytes --]
[-- Attachment #3: diald-1.01-utils.patch.bz2 --]
[-- Type: application/octet-stream, Size: 1290 bytes --]
[-- Attachment #4: diald-1.01-tundoc.patch.bz2 --]
[-- Type: application/octet-stream, Size: 1081 bytes --]
^ permalink raw reply
* Re: need arguments to use JFFS2
From: Charles Manning @ 2002-12-07 8:35 UTC (permalink / raw)
To: David Woodhouse, Chantara Thlang; +Cc: linux-mtd
In-Reply-To: <28792.1039171331@passion.cambridge.redhat.com>
It is virtually impossible to make any firm statements without understanding
your needs a bit better.
A few others have already covered cramfs and JFFSx. I can tell you a bit
about YAFFS.
YAFFS only works with NAND flash. YAFFS does not provide compression (like
JFFS does). YAFFS is faster than JFFS2 in most situations and uses less RAM.
Mileage will vary though. Compression is not necessarily a huge advantage for
JFFSx. Some people loop-mount a cramfs image stored on YAFFS to get the
benefits of compression as well as the faster speed for other files.
If you have NAND, then most likely YAFFS will serve you better for larger
flash arrays (say 16MB and bigger) and JFFS2 for smaller arrays.
YAFFS will do nothing for you if you only have NOR flash.
If you're designing a new board then consider including NAND flash for
storage (rather than NOR). NAND is cheaper, smaller (physically), bigger (in
bytes) and faster. You can then use YAFFS or JFFS2 (even both - by
partitioning the device).
-- Charles
^ permalink raw reply
* Re: /proc/pci deprecation?
From: Willy Tarreau @ 2002-12-07 7:44 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: Patrick Mochel, linux-kernel, Linus Torvalds, jgarzik
In-Reply-To: <997222131F7@vcnet.vc.cvut.cz>
On Sat, Dec 07, 2002 at 12:18:05AM +0100, Petr Vandrovec wrote:
> It is invaluable during installation, when no lspci is installed yet.
> I know that I need e100/eepro100 for
> 'Ethernet controller: Intel Corp. 82801BA/BAM/CA/CAM E', but I do not
> have even slightest idea what device 8086:2449 is, whether USB or NIC or
> VGA or some bridge.
at least, the file "modules.pcimap" tells you which modules support these
devices, by vendor/model codes. I once developped a little installation script
which loaded all the NICs it could by listing /proc/bus/pci/devices and
modules.pcimap. I too agree that names in /proc/pci are *really* useful, but I
often omit them when I need a very little image. Perhaps having a list of names
only for devices supported by the kernel and modules at compile time would be
an acceptable compromise ?
Regards,
Willy
^ permalink raw reply
* Re: Re[2]: [STATUS] fbdev api.
From: Antonino Daplas @ 2002-12-07 10:22 UTC (permalink / raw)
To: Tobias Rittweiler
Cc: James Simmons, Linux Kernel Mailing List, Linux console project
In-Reply-To: <15835232027.20021206235940@uni.de>
[-- Attachment #1: Type: text/plain, Size: 2447 bytes --]
On Sat, 2002-12-07 at 03:59, Tobias Rittweiler wrote:
[...]
> >> c) instruction: | produces:
> >> ======================|==================
> >> 1. typing abc def | $ abc def
> >> | ^ (<- cursor)
> >> 2. going three chars | $ abc def
> >> ro the left | ^
> >> 3. pressing backspace | $ abcddef
> >> | ^
> >> 4. pressing enter | -bash: abcdef: command not found
> >> |
>
> AD> I get this also. Seems to occur only with colored terms. When I do
>
> AD> set TERM=vt100
>
> AD> the problem disappears, so I thought this was an isolated case with my
> AD> setup :-). Similar glitches happen also in emacs with syntax
> AD> highlighting turned on.
>
> Still there.
>
Can you try this? It should fix the problem you mentioned as well as the
emacs glitch. Also, a quick fix for character map generation failures
(KDFONTOP ioctl), ie when selecting console fonts. Finally, if fbdev
supports blanking, let's use that.
diff -Naur linux-2.5.50-js/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.50-js/drivers/video/console/fbcon.c 2002-12-07 10:10:40.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2002-12-07 10:12:11.000000000 +0000
@@ -357,7 +357,7 @@
area.dx = dx * vc->vc_font.width;
area.dy = dy * vc->vc_font.height;
area.height = height * vc->vc_font.height;
- area.width = width * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
info->fbops->fb_copyarea(info, &area);
}
@@ -910,6 +910,12 @@
info->var.xoffset = info->var.yoffset = p->yscroll = 0; /* reset wrap/pan */
+ /*
+ * FIXME: need to set this in order for KDFONTOP ioctl
+ * to work
+ */
+ p->fontwidthmask = FONTWIDTHRANGE(1,16);
+
for (i = 0; i < MAX_NR_CONSOLES; i++)
if (i != con && fb_display[i].fb_info == info &&
fb_display[i].conp && fb_display[i].fontdata)
@@ -1987,12 +1993,9 @@
else
update_screen(vc->vc_num);
return 0;
- } else {
- /* Tell console.c that it has to restore the screen itself */
- return 1;
- }
- fb_blank(blank, info);
- return 0;
+ }
+ else
+ return info->fbops->fb_blank(blank, info);
}
static void fbcon_free_font(struct display *p)
Tony
PS: James, can you also apply the following riva cleanup patch. It
fixes compile failures as well as removal of unused defines and
declarations.
Thanks.
[-- Attachment #2: rivafb.diff --]
[-- Type: text/x-patch, Size: 2999 bytes --]
diff -Naur linux-2.5.50-js/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.50-js/drivers/video/riva/fbdev.c 2002-12-07 09:50:22.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c 2002-12-07 09:53:45.000000000 +0000
@@ -214,31 +214,6 @@
};
MODULE_DEVICE_TABLE(pci, rivafb_pci_tbl);
-
-
-/* ------------------------------------------------------------------------- *
- *
- * framebuffer related structures
- *
- * ------------------------------------------------------------------------- */
-
-extern struct display_switch fbcon_riva8;
-extern struct display_switch fbcon_riva16;
-extern struct display_switch fbcon_riva32;
-
-struct riva_cursor {
- int enable;
- int on;
- int vbl_cnt;
- int last_move_delay;
- int blink_rate;
- struct {
- u16 x, y;
- } pos, size;
- unsigned short image[MAX_CURS*MAX_CURS];
- struct timer_list *timer;
-};
-
/* ------------------------------------------------------------------------- *
*
* global variables
@@ -1167,7 +1142,7 @@
if (!cnt) {
memset(&par->state, 0, sizeof(struct fb_vgastate));
- par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONTS;
+ par->state.flags = VGA_SAVE_MODE | VGA_SAVE_FONT0;
/* save the DAC for Riva128 */
if (par->riva.Architecture == NV_ARCH_03)
par->state.flags |= VGA_SAVE_CMAP;
@@ -1189,11 +1164,10 @@
if (!cnt)
return -EINVAL;
if (cnt == 1) {
- par->riva.LockUnlock(&par->riva, 0);
- par->riva.LoadStateExt(&par->riva, &par->initial_state.ext);
+ riva_load_state(par, &par->initial_state);
+ par->riva.LockUnlock(&par->riva, 1);
fb_restore_vga(&par->state);
- par->riva.LockUnlock(&par->riva, 1);
}
atomic_dec(&par->ref_count);
@@ -1566,6 +1540,16 @@
fb_find_mode(&info->var, info, mode_option,
NULL, 0, NULL, 8);
#endif
+
+ info->var.yres_virtual = -1;
+ info->var.xres_virtual = info->var.xres;
+ if (rivafb_check_var(&info->var, info))
+ return 1;
+
+ info->fix.line_length = (info->var.xres_virtual * (info->var.bits_per_pixel >> 3));
+ info->fix.visual = (info->var.bits_per_pixel == 8) ?
+ FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
+
return 0;
}
@@ -1883,10 +1867,8 @@
while ((this_opt = strsep(&options, ",")) != NULL) {
if (!*this_opt)
continue;
- if (!strncmp(this_opt, "nomove", 6)) {
- nomove = 1;
#ifdef CONFIG_MTRR
- } else if (!strncmp(this_opt, "nomtrr", 6)) {
+ if (!strncmp(this_opt, "nomtrr", 6)) {
nomtrr = 1;
#endif
} else
@@ -1935,8 +1917,6 @@
MODULE_PARM_DESC(font, "Specifies one of the compiled-in fonts (default=none)");
MODULE_PARM(noaccel, "i");
MODULE_PARM_DESC(noaccel, "Disables hardware acceleration (0 or 1=disabled) (default=0)");
-MODULE_PARM(nomove, "i");
-MODULE_PARM_DESC(nomove, "Enables YSCROLL_NOMOVE (0 or 1=enabled) (default=0)");
#ifdef CONFIG_MTRR
MODULE_PARM(nomtrr, "i");
MODULE_PARM_DESC(nomtrr, "Disables MTRR support (0 or 1=disabled) (default=0)");
^ permalink raw reply
* Re: [Linux-ia64] ia64 arch makefile update
From: Sam Ravnborg @ 2002-12-07 7:18 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805512@msgid-missing>
On Fri, Dec 06, 2002 at 11:41:41PM +0100, Sam Ravnborg wrote:
> Hi all.
> Following is an update of various ia64 specific makefiles.
> Patch is on top of linus-latest, with the 2.5.50 ia64 patch posted here applied.
>
> Summary of changes:
> o Simplified arch/ia64/Makefile
> - During this process the boot: target were removed
> o Moved final generation of vmlinux.gz to boot/Makefile
> - This allowed me to use some of the kbuild infrastructure
> - Final file "vmlinux.gz" is now saved in arch/ia64/boot in line with
> other architectures.
> o s/$(ARCH)/ia64 - since we know that this is the architecture we use
> o Small clean up all over, e.g. removed inclusion of Rules.make
> Also made some nicer indenting, but no functional changes.
I have been requested to enable the following scenario:
$ make
$ ski bootloader vmlinux
And I also have realised that
$ make boot
is used when compiling for the simulator only.
So I will send an update during the weekend, as Real Life(tm) permits ;-)
Sam
^ permalink raw reply
* Re: port forwarding
From: Andrew Smith @ 2002-12-07 7:16 UTC (permalink / raw)
To: netfilter
In-Reply-To: <285598680.20021205235627@rtsnet.ru>
If they want to play on an external server then there is
nothing required other than standard masquerading/nat
HOWEVER, if you resrtict outgoing (and return) ports then
you need to allow UDP on port 21705
(I'm not sure if TCP is used at all?)
WARNING
if 3 or 4 people do a standard full server update at the
same time it will fill your conntrack table and you will
start dropping other connections for a while
Counterstrike is beyond the tiny limitation of a 64K conntrack
table and since you cannot specifically say to timeout the
counterstrike server update connections quickly (due to the
fact that you will never need to do this - yeah I know that's
wrong but ... that's what the netfilter developers say)
you end up filling the conntrack table
You need to be able to set it to handle about 20,000 connections
per user that is using Counterstrike but I think it is limited
to only 64K - but I'm not 100% certain.
Anyone know for sure if there is a small limit in the size of
the conntrack table? Hopefully there isn't ... but others have
said otherwise. Maybe that has change recently?
> Hello all,
>
> Players at my office asks me to give them access to outside
> counterstrike server, UDP 21705. unfortunatelly, i am brand new in
> iptables, so i've read the docs and started make rules, but they does
> not work.
> Then i've tried simple
> root@woody~/iptables>cat 1.sh
> #!/bin/sh
> echo 1 > /proc/sys/net/ipv4/ip_forward
> iptables -v -F -t nat
> iptables -v -F
> iptables -v -A FORWARD -p tcp --dport 205 -j ACCEPT
> iptables -v -t nat -A PREROUTING -p tcp --dport 205 -j DNAT
> --to-destination 172.17.32.12:25
>
> , then telnet to woody:205 and there is no refusal and no answer.
>
> root@woody~/iptables>cat /proc/net/ip_conntrack
> [...]
> tcp 6 118 SYN_SENT src=172.17.32.5 dst=172.17.144.110 sport=2020
> dport=205 [UNREPLIED] src=172.17.32.12 dst=172.17.32.5 sport=25
> dport=2020 use=1
>
> Can someone please tell me, what i am doing wrong? why [UNREPLIED]?
> should i create rule to pass packets back from 172.17.32.5 to client?
>
> p.s. iptables v1.2.6a, kernel 2.4.18
>
> Best wishes,
> Maxim mailto:mak@rtsnet.ru
^ permalink raw reply
* [linux-lvm] snapshot file zombies
From: Jürgen Vollmer @ 2002-12-07 6:52 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
Hi dear list,
I created a snapshot from my /home to do my usual backup with tar.
Then I got 15 messages of the kind
tar: lvm-snapshot/vollmer/Mail/inbox/,120: can not stat, no permission
(or so it's translated from german to englich by me)
doing a
find /lvm-snapshot/vollmer/Mail/inbox/ -name ",120"
rsults in
/lvm-snapshot/vollmer/Mail/inbox/,120
so the file exists, but:
ls -l /lvm-snapshot/vollmer/Mail/inbox/,120
results in
ls: /lvm-snapshot/vollmer/Mail/inbox/,120: Permission denied
get some infos via find:
find /lvm-snapshot/vollmer/Mail/inbox/ -name ",120" -print "-A@"
results in:
find: /lvm-snapshot/vollmer/Mail/inbox/,120: Permission denied
The "original file" ~vollmer/Mail/inbox/,120 is ok and readable.
Two weeks ago everything worked fine.
So what's wrong with it? Is my corrupted? (tar --compare seems to complain
only at those files).
I use SuSe 8.1, Logical Volume Manager 1.0.5(mp-v6)
With best regards
Jürgen
--
Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe
Tel: +49(721) 9204871 Fax: +49(721) 24874
juergen@informatik-vollmer.de,vollmer@cocolab.de,Juergen.Vollmer@acm.org
www.informatik-vollmer.de
[-- Attachment #2: Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [BENCHMARK] max bomb segment tuning with read latency 2 patchin contest
From: Andrew Morton @ 2002-12-07 6:45 UTC (permalink / raw)
To: GrandMasterLee; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <1039242017.2855.26.camel@localhost>
GrandMasterLee wrote:
>
> ...
> One interesting thing about my current setup, with all scsi or FC disks,
> is that bomb never displays > 0.
> Example:
>
> elvtune /dev/sdn yields:
>
> /dev/sdn elevator ID 17
> read_latency: 8192
> write_latency: 16384
> max_bomb_segments: 0
>
> elvtune -b 6 /dev/sdn yields:
>
> /dev/sdn elevator ID 17
> read_latency: 8192
> write_latency: 16384
> max_bomb_segments: 0
>
> Is it because I just do volume management at the hardware level and use
> whole disks? Or is that something else?
You need a patched kernel. max_bomb_segments is some old thing
which isn't implemented any more. But I reused it for something
completely different in the patch which Con is testing. So I
wouldn't have to futz around with patching userspace apps.
^ permalink raw reply
* Re: Propert IPTABLES Configuration
From: Bob Sully @ 2002-12-07 6:24 UTC (permalink / raw)
To: james.Q.L; +Cc: netfilter
In-Reply-To: <20021207053208.86183.qmail@web14503.mail.yahoo.com>
Hey guys...I used to run a CS server on one of my machines. This worked
for me:
# GAMES
# Half-Life/CounterStrike
#
if [ $HALF_LIFE -gt 0 ]; then
iptables -A OUTPUT -o $EXTERNAL_INTERFACE -p UDP \
--sport 27000:27050 --dport $UNPRIVPORTS -s $EXTERNAL_IP -d \
$ANYWHERE -j ACCEPT
iptables -A INPUT -i $EXTERNAL_INTERFACE -p UDP \
--sport $UNPRIVPORTS --dport 27000:27050 -s $ANYWHERE -d \
$EXTERNAL_IP -j ACCEPT
if [ $VERBOSE -gt 0 ]; then
echo "firewall: Half-Life/CounterStrike ports enabled"
fi
fi
where:
$EXTERNAL_INTERFACE = eth0 in my case
$EXTERNAL_IP = obvious
$UNPRIVPORTS = 1024:65535
$ANYWHERE = any/0
HTH -- Bob
On Sat, 7 Dec 2002, james.Q.L wrote:
> --- Rob <netfilter@cloudtown.com> wrote: > I am attempting to setup a Half-Life Counter-Strike
> Server on my
> > machine. I need
> > it setup so people can access it from the internet and my intranet.
> >
> > I found the following ports I need setup.
> >
> > TCP 6003 outbound, incoming replies (as specified in woncomm.lst)
> > TCP 7002 outbound, incoming replies (as specified in woncomm.lst)
> > UDP 27010 outbound, incoming replies (as specified in woncomm.lst)
> > UDP 27011 outbound, incoming replies (as specified in woncomm.lst)
> > UDP 27012 outbound, incoming replies (as specified in woncomm.lst)
> > UDP 27013 outbound, incoming replies
> > UDP 27015 outbound, incoming replies on 27015-27050
>
> i remember that 6003, 7001, 7002 are used for authentication and server lists.
> so if you want only invite ppl join. maybe it's fine just open 27015 port.
> someone correct me if i am wrong.
>
> >
> > would something like this be right?
> >
> > IPTABLES -A INPUT -i eth0 -p tcp -s any/0 -d any/0 --dport 6003 -m state
> > --state ESTABLISHED,RELATED -j ACCEPT
>
> this will reject you friends who want to join the server by typing the ip in the game console.
>
> > with that in mind would I have to create an output for each one too?
> >
> > IPTABLES -A OUTPUT -o eth0 -p tcp --dport 6003 -m state --state
> > NEW,ESTABLISHED,RELATED -j ACCEPT
>
> using NEW,ESTABLISHED,RELATED is the same as just saying "-j ACCEPT"
> i think you want to allow "ESTABLISHED,RELATED " out.
>
> IPTABLES -A OUTPUT -o eth0 -p tcp --dport 6003 -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> > Thanks for your help.
> >
> > Rob
--
________________________________________
Bob Sully - Simi Valley, California, USA
http://www.malibyte.net
"The weather is here - wish you were beautiful." - J. Buffett
^ permalink raw reply
* Re: [BENCHMARK] max bomb segment tuning with read latency 2 patch in contest
From: GrandMasterLee @ 2002-12-07 6:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3DF18D38.F493636C@digeo.com>
On Fri, 2002-12-06 at 23:55, Andrew Morton wrote:
[...]
> If the SMP machine is using scsi then that tends to make the elevator
> changes less effective. Because the disk sort-of has its own internal
> elevator which in my testing on a Fujitsu disk has the same ill-advised
> design as the kernel's elevator: it treats reads and writes in a similar
> manner.
>
> Setting the tag depth to zero helps heaps.
>
> But as you're interested in `desktop responsiveness' you should be
> mostly testing against IDE disks. Their behavour tends to be quite
> different.
One interesting thing about my current setup, with all scsi or FC disks,
is that bomb never displays > 0.
Example:
elvtune /dev/sdn yields:
/dev/sdn elevator ID 17
read_latency: 8192
write_latency: 16384
max_bomb_segments: 0
elvtune -b 6 /dev/sdn yields:
/dev/sdn elevator ID 17
read_latency: 8192
write_latency: 16384
max_bomb_segments: 0
Is it because I just do volume management at the hardware level and use
whole disks? Or is that something else?
^ permalink raw reply
* RE: POSSIBLE BUG: Debugging Not Automatically Activated in Slab.c -- RESOLVED
From: Joseph D. Wagner @ 2002-12-07 6:17 UTC (permalink / raw)
To: 'Randy.Dunlap'; +Cc: 'Linux Kernel Development List'
In-Reply-To: <Pine.LNX.4.33L2.0212062105520.27850-100000@dragon.pdx.osdl.net>
Thanks for the non-flame clarification.
Joseph Wagner
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Randy.Dunlap
Sent: Friday, December 06, 2002 11:08 PM
To: Joseph D. Wagner
Cc: 'Linux Kernel Development List'
Subject: Re: POSSIBLE BUG: Debugging Not Automatically Activated in Slab.c
On Fri, 6 Dec 2002, Joseph D. Wagner wrote:
| Before I submit this as an actually bug, I'd like the input of some people
| who know a little more about the Slab Allocator and Kernel Debugging.
|
| The Slab Allocator includes this line:
|
| #ifdef CONFIG_DEBUG_SLAB
|
| in slab.c (line 89) to activate debugging.
|
| However, I couldn't find anywhere in the code where CONFIG_DEBUG_SLAB is
| linked to CONFIG_DEBUG_KERNEL. In other words, setting the kernel as a
| debug kernel doesn't automatically set the Slab Allocator to debug too.
CONFIG_DEBUG_SLAB is a separate option, listed under the
Kernel Hacking config menu (Debug memory allocations).
| 1) Am I missing something?
|
| 2) Is this intentional or by design?
Design.
| If this is an actually bug, it can be fixed by inserting the following
code
| in slab.h immediately following the #include statements:
|
| #ifdef CONFIG_DEBUG_KERNEL
| #define CONFIG_DEBUG_SLAB
| #endif
Nope, just enable it.
--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [BENCHMARK] max bomb segment tuning with read latency 2 patch in contest
From: GrandMasterLee @ 2002-12-07 6:15 UTC (permalink / raw)
To: Andrew Morton; +Cc: Con Kolivas, linux kernel mailing list
In-Reply-To: <3DF18D38.F493636C@digeo.com>
On Fri, 2002-12-06 at 23:55, Andrew Morton wrote:
[...]
> If the SMP machine is using scsi then that tends to make the elevator
> changes less effective. Because the disk sort-of has its own internal
> elevator which in my testing on a Fujitsu disk has the same ill-advised
> design as the kernel's elevator: it treats reads and writes in a similar
> manner.
>
> Setting the tag depth to zero helps heaps.
Command tag queue? As in the compile time option? Or do you mean queue
depth?(or are they the same)
> But as you're interested in `desktop responsiveness' you should be
> mostly testing against IDE disks. Their behavour tends to be quite
> different.
>
> If you can turn on write caching on the SCSI disks that would change
> the picture too.
Just for clarity, What about for something like FC attached storage
Where the controllers enforce cache policies on a "per volume" basis?
Would that == the same thing?
--The GrandMaster
^ permalink raw reply
* Re: [BENCHMARK] max bomb segment tuning with read latency 2 patch in contest
From: Andrew Morton @ 2002-12-07 6:14 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux kernel mailing list
In-Reply-To: <200212071709.50023.conman@kolivas.net>
Con Kolivas wrote:
>
> ...
> >If the SMP machine is using scsi then that tends to make the elevator
> >changes less effective. Because the disk sort-of has its own internal
> >elevator which in my testing on a Fujitsu disk has the same ill-advised
> >design as the kernel's elevator: it treats reads and writes in a similar
> >manner.
>
> These are ide disks, in the same format as those used in the UP machine, so it
> still should be showing the same effect? I think higher numbers in UP would
> increase the resolution more for these results - apart from that is there any
> disadvantage to doing it in SMP? If you think it's worth running them in UP
> mode I'll do that.
Oh, OK. I was guessing, and guessed wrong. No, I don't expect you'd
see much difference switching to UP for those tests which are sensitive
to the IO scheduler policy.
^ permalink raw reply
* Re: A20 Address line - XMS issue
From: S.Gopi @ 2002-12-07 6:05 UTC (permalink / raw)
To: Bart Oldeman; +Cc: linux-msdos
In-Reply-To: <Pine.LNX.4.33.0212061604260.6814-100000@DHCP-94-246.math.ohio-state.edu>
--- Bart Oldeman <oldeman@math.ohio-state.edu> wrote:
>
> HIMEM.SYS services are *provided* by DOSEMU.
> HIMEM.SYS might be able to
> run in DOSEMU if DOSEMU would implement int
> 0x15/0x87 to copy extended
> memory though. However it's a fairly pointless
> exercise unless you really
> need some very special use.
it looks fine, if dosemu can emulated these interrupt
calls and do memory paging in the protected mode
itself with given virtual memory(something like what
is being done in the XMS now) it would make it
possible to use HIMEM.sys
>
>
> a) dosemu does not implement int15/0x87
> b) dosemu emulates A20 through these calls
> 1. XMS driver calls ah=3/4/5/6/7.
> 2. the relevant I/O port (keyboard related).
> using a paging technique. The XMS driver API (in
> real DOS this
> API is provided by HIMEM or FreeDOS FDXMS) has
> been in DOSEMU
> for ages. The port technique became necessary
> when we found out that
> Windows ME DOS bootdisks use that.
>
>
> himem.sys might run, but VCPI support is out of the
> question without CPU
> emulation; VCPI needs ring-0 access.
fine, what is the effort that needs to be put on this,
I mean is that possible to do it with current dosemu
distribution itself with little bit of code hack. I
would like to do it since this is very much important
for the project i am involved in.
gopi
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: [BENCHMARK] max bomb segment tuning with read latency 2 patch in contest
From: Con Kolivas @ 2002-12-07 6:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux kernel mailing list
In-Reply-To: <3DF18D38.F493636C@digeo.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>Con Kolivas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Here are some io_load contest benchmarks with 2.4.20 with the read
>> latency2 patch applied and varying the max bomb segments from 1-6 (SMP
>> used to save time!)
>>
>> io_load:
>> Kernel [runs] Time CPU% Loads LCPU% Ratio
>> 2.4.20 [5] 164.9 45 31 21 4.55
>> 2420rl2b1 [5] 93.5 81 18 22 2.58
>> 2420rl2b2 [5] 88.2 87 16 22 2.44
>> 2420rl2b4 [5] 87.8 84 17 22 2.42
>> 2420rl2b6 [5] 100.3 77 19 22 2.77
>
>If the SMP machine is using scsi then that tends to make the elevator
>changes less effective. Because the disk sort-of has its own internal
>elevator which in my testing on a Fujitsu disk has the same ill-advised
>design as the kernel's elevator: it treats reads and writes in a similar
>manner.
These are ide disks, in the same format as those used in the UP machine, so it
still should be showing the same effect? I think higher numbers in UP would
increase the resolution more for these results - apart from that is there any
disadvantage to doing it in SMP? If you think it's worth running them in UP
mode I'll do that.
>
>Setting the tag depth to zero helps heaps.
>
>But as you're interested in `desktop responsiveness' you should be
>mostly testing against IDE disks. Their behavour tends to be quite
>different.
>
>If you can turn on write caching on the SCSI disks that would change
>the picture too.
>
>> io_other:
>> Kernel [runs] Time CPU% Loads LCPU% Ratio
>> 2.4.20 [5] 89.6 86 17 21 2.47
>> 2420rl2b1 [3] 48.1 156 9 21 1.33
>> 2420rl2b2 [3] 50.0 149 9 21 1.38
>> 2420rl2b4 [5] 51.9 141 10 21 1.43
>> 2420rl2b6 [5] 52.1 142 9 20 1.44
>>
>> There seems to be a limit to the benefit of decreasing max bomb segments.
>> It does not seem to have a significant effect on io load on another hard
>> disk (although read latency2 is overall much better than vanilla).
>
>hm. I'm rather surprised it made much difference at all to io_other,
>because you shouldn't have competing reads and writes against either
>disk??
Some of the partitions are mounted on that other disk as well so occasionally
it is involved in the kernel compile.
/dev/hda8 on / type ext3 (rw)
none on /proc type proc (rw)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hda7 on /home type ext3 (rw)
/dev/hda5 on /tmp type ext3 (rw)
/dev/hdb5 on /usr type ext3 (rw)
/dev/hdb1 on /var type ext3 (rw)
The testing is done from /dev/hda7 and io_load writes to /dev/hda7, io_other
writes to /dev/hdb1
Unfortunately this is the way the osdl machine was set up for me. I should
have been more specific in my requests but I didnt realise they were doing
this. There isn't really that much spare space on the two drives to shuffle
the partitioning around and contest can use huge amounts of space during
testing :\
>The problem with io_other should be tickling is where `gcc' tries to
>allocate a page but ends up having to write out someone else's data,
>and gets stuck sleeping on the disk queue due to the activity of
>other processes. (This doesn't happen much on a 4G machine, but it'll
>happen a lot on a 256M machine).
>
>But that's a write-latency problem, not a read-latency one.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE98ZCsF6dfvkL3i1gRAtAJAKCipF5dOAp2g+ICRuV4xagT/qsvZgCfWhaN
eZsoUGwt5RjlGbZJiD+nYZI=
=OVHE
-----END PGP SIGNATURE-----
^ permalink raw reply
* uml-patch-2.5.50-1
From: Jeff Dike @ 2002-12-07 6:07 UTC (permalink / raw)
To: linux-kernel, user-mode-linux-devel
This patch updates UML to 2.5.50. As far as UML itself is concerned, this
is identical to 2.5.49.
NOTE: I get reproducable filesystem corruption with this version. Offhand,
it doesn't look like my fault, so I'm releasing it anyway. I didn't notice
any such complaints (or fixes) about 2.5.50 on lkml, but it's possible I
wasn't paying enough attention. If there is a fix, apply it first. If not,
then run this version on a filesystem that you can afford to have trashed.
The 2.5.50 UML patch is available at
http://uml-pub.ists.dartmouth.edu/uml/uml-patch-2.5.50-1.bz2
For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html
Other links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
Jeff
^ permalink raw reply
* Re: [BENCHMARK] max bomb segment tuning with read latency 2 patch in contest
From: Andrew Morton @ 2002-12-07 5:55 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux kernel mailing list
In-Reply-To: <200212071620.05503.conman@kolivas.net>
Con Kolivas wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Here are some io_load contest benchmarks with 2.4.20 with the read latency2
> patch applied and varying the max bomb segments from 1-6 (SMP used to save
> time!)
>
> io_load:
> Kernel [runs] Time CPU% Loads LCPU% Ratio
> 2.4.20 [5] 164.9 45 31 21 4.55
> 2420rl2b1 [5] 93.5 81 18 22 2.58
> 2420rl2b2 [5] 88.2 87 16 22 2.44
> 2420rl2b4 [5] 87.8 84 17 22 2.42
> 2420rl2b6 [5] 100.3 77 19 22 2.77
If the SMP machine is using scsi then that tends to make the elevator
changes less effective. Because the disk sort-of has its own internal
elevator which in my testing on a Fujitsu disk has the same ill-advised
design as the kernel's elevator: it treats reads and writes in a similar
manner.
Setting the tag depth to zero helps heaps.
But as you're interested in `desktop responsiveness' you should be
mostly testing against IDE disks. Their behavour tends to be quite
different.
If you can turn on write caching on the SCSI disks that would change
the picture too.
> io_other:
> Kernel [runs] Time CPU% Loads LCPU% Ratio
> 2.4.20 [5] 89.6 86 17 21 2.47
> 2420rl2b1 [3] 48.1 156 9 21 1.33
> 2420rl2b2 [3] 50.0 149 9 21 1.38
> 2420rl2b4 [5] 51.9 141 10 21 1.43
> 2420rl2b6 [5] 52.1 142 9 20 1.44
>
> There seems to be a limit to the benefit of decreasing max bomb segments. It
> does not seem to have a significant effect on io load on another hard disk
> (although read latency2 is overall much better than vanilla).
hm. I'm rather surprised it made much difference at all to io_other,
because you shouldn't have competing reads and writes against either
disk??
The problem with io_other should be tickling is where `gcc' tries to
allocate a page but ends up having to write out someone else's data,
and gets stuck sleeping on the disk queue due to the activity of
other processes. (This doesn't happen much on a 4G machine, but it'll
happen a lot on a 256M machine).
But that's a write-latency problem, not a read-latency one.
^ permalink raw reply
* Re: 2.4.18 beats 2.5.50 in hard drive access????
From: David Ashley @ 2002-12-07 5:51 UTC (permalink / raw)
To: tadams-lists; +Cc: linux-kernel
hdparm -t yields similiar results on 2.4.18 and 2.5.50. What is a huge
difference is the scattered reads from a disk. At least it is good to
see other people experiencing similiar kernel messages. Would it help to
post the program? Here it is anyway:
Thanks--
Dave
//compile with
//gcc t.c -o t -lpthread
#include <stdio.h>
#include <stdlib.h>
#include <linux/fcntl.h>
#include <unistd.h>
#include <linux/unistd.h>
#include <sys/time.h>
#include <pthread.h>
char DEVNAME[128];
extern long long lseek64(int,long long,int);
unsigned char *tbuff;
long long now(void)
{
struct timeval tv;
gettimeofday(&tv,0);
return tv.tv_sec*1000000ll + tv.tv_usec;
}
int intcomp(const void *v1,const void *v2)
{
return *(unsigned long *)v1 - *(unsigned long *)v2;
}
#define NUM 250
#define BLOCK (188*128*4ll)
int fd;
long long l;
char state[NUM];
void *readfunc(void *a)
{
long long off;
int lfd;
int r;
lfd=open(DEVNAME,O_RDONLY|O_LARGEFILE|O_SYNC);
off=(rand()&0x7fffffff)%l*BLOCK;
lseek64(lfd,off,SEEK_SET);
r=read(lfd,tbuff,BLOCK);
state[(int)a]=1;
close(lfd);
return 0;
}
int main(int argc,char **argv)
{
long long lres;
int res;
int i,j;
long long start,off;
unsigned char *p;
if(argc<2) {printf("specify device to test\n");exit(0);}
strcpy(DEVNAME,argv[1]);
tbuff=malloc(BLOCK+4096);
fd=open(argv[1],O_RDONLY|O_LARGEFILE);
printf("fd=%d\n",fd);
if(fd<0) exit(0);
while((int)tbuff & 4095) ++tbuff; // align to PAGE_SIZE
l=lseek64(fd,0ll,SEEK_END);
printf("Total volume size=%lld megabytes\n",l/0x100000);
l/=BLOCK;
printf("%d blocks\n",l);
start=now();
srand((int)start);
for(i=0;i<NUM;++i)
{
pthread_t tt;
memset(&tt,0,sizeof(tt));
pthread_create(&tt,0,readfunc,(void *)i);
}
for(;;)
{
for(i=0;i<NUM;++i)
if(!state[i]) break;
if(i==NUM) break;
usleep(10000);
}
start=now()-start;
printf("%f seconds\n",start/(float)1000000.0);
printf("%f mbytes/second\n",(float)BLOCK*NUM/start);
return 0;
}
^ permalink raw reply
* Re: Re: [BK PATCH] ACPI updates
From: Sérgio Monteiro Basto @ 2002-12-07 5:42 UTC (permalink / raw)
To: acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <20021206165004.GE7961-jyMamyUUXNJG4ohzP4jBZS1Fcj925eT/@public.gmane.org>
Tell him to buy a compaq pressario Laptop to see if it change the ideas.
Now many new laptops doesn't work without acpi, isn't this is true ?
Sérgio Basto
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.