Upgrade to mt-st version .5b or greater. Older mt versions had known
bugs particularly with positioning. I suggest scsi emulation + scsi
tape rather than ATAPI tape.
rgds,
tim.
...
hdd: HP COLORADO 20GB, ATAPI TAPE drive
...
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
scsi : 1
Upgrade to mt-st version .5b or greater. Older mt versions had known
bugs particularly with positioning. I suggest scsi emulation + scsi
tape rather than ATAPI tape.
rgds,
tim.
...
hdd: HP COLORADO 20GB, ATAPI TAPE drive
...
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
scsi : 1
[EMAIL PROTECTED] wrote:
>
> Well considering the other night the power supply went dead, I think that is part of
>the problem. It is brand new, and I am being sent another one (free of course).
>
> I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd,
>Sound
> Some ASUS boards (mostly P3B-F) would either freeze or self reboot when using
> PhotoShop 5. Everything else would run perfectly.
>
> Disabling MMX optimizations in this software would "solve" the problem. Another
> solution found on the web (sorry, I don't have the URL at hand) is to add two
Some ASUS boards (mostly P3B-F) would either freeze or self reboot when using
PhotoShop 5. Everything else would run perfectly.
Disabling MMX optimizations in this software would solve the problem. Another
solution found on the web (sorry, I don't have the URL at hand) is to add two
or
[EMAIL PROTECTED] wrote:
Well considering the other night the power supply went dead, I think that is part of
the problem. It is brand new, and I am being sent another one (free of course).
I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd,
Sound card,
[EMAIL PROTECTED] wrote:
> ...
> 2. A "ping -f -s 64589" to a machine running kernel 2.2.19 results in 0%
> packet loss. By incrementing the packetsize by one "ping -f -s 64590" or
> higher, I consistently see 80% packet loss. ifconfig on the receiving
> machine shows no anomolies.
> ...
> 4.
José Luis Domingo López wrote:
>
> On Thursday, 14 June 2001, at 14:17:11 -0700,
> [EMAIL PROTECTED] wrote:
>
> >
> > 1. When pinging a machine using kernel 2.2.19 I consistently get an 80%
> > packet loss when doing a ping -f with a packet size of 64590 or higher.
> >
> What happens here is
[EMAIL PROTECTED] wrote:
...
2. A ping -f -s 64589 to a machine running kernel 2.2.19 results in 0%
packet loss. By incrementing the packetsize by one ping -f -s 64590 or
higher, I consistently see 80% packet loss. ifconfig on the receiving
machine shows no anomolies.
...
4. Linux version
José Luis Domingo López wrote:
On Thursday, 14 June 2001, at 14:17:11 -0700,
[EMAIL PROTECTED] wrote:
1. When pinging a machine using kernel 2.2.19 I consistently get an 80%
packet loss when doing a ping -f with a packet size of 64590 or higher.
What happens here is (under kernel
v2.10r works.
[tim@abit tim]# mount -V
mount: mount-2.10r
[tim@abit tim]# tune2fs -L spare /dev/hda10
tune2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
[tim@abit tim]# mount -L spare /mnt
[tim@abit tim]# df /mnt
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda10
v2.10r works.
[tim@abit tim]# mount -V
mount: mount-2.10r
[tim@abit tim]# tune2fs -L spare /dev/hda10
tune2fs 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09
[tim@abit tim]# mount -L spare /mnt
[tim@abit tim]# df /mnt
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda10
While browsing IBM ThinkPads online I noticed only one high-end
model with linux. I called 1-888-SHOP-IBMx7000 (phone sales)
to inquire how to get a ThinkPad without Windows given I would
be immediately installing linux.
I was offered 6% off the online price for any Thinkpad which in
my case
While browsing IBM ThinkPads online I noticed only one high-end
model with linux. I called 1-888-SHOP-IBMx7000 (phone sales)
to inquire how to get a ThinkPad without Windows given I would
be immediately installing linux.
I was offered 6% off the online price for any Thinkpad which in
my case
Any clues as to why /dev/st0 is never initialized for DAT tape? Please cc
[EMAIL PROTECTED] if more
info is needed.
rgds,
tim.
...
ncr53c8xx: at PCI bus 1, device 9, function 0
ncr53c8xx: 53c876 detected
ncr53c8xx: at PCI bus 1, device 9, function 1
ncr53c8xx: 53c876 detected
ncr53c876-0:
> > to do is be able to write to the tape, but not read from it.
> > Even in 2.2.x, putting the IDE patches in, breaks it. Apparently
> > the HP's aren't completely ATAPI compatible
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
scsi : 1 host.
Vendor: HPModel: COLORADO 20GB
to do is be able to write to the tape, but not read from it.
Even in 2.2.x, putting the IDE patches in, breaks it. Apparently
the HP's aren't completely ATAPI compatible
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
scsi : 1 host.
Vendor: HPModel: COLORADO 20GB
Any clues as to why /dev/st0 is never initialized for DAT tape? Please cc
[EMAIL PROTECTED] if more
info is needed.
rgds,
tim.
...
ncr53c8xx: at PCI bus 1, device 9, function 0
ncr53c8xx: 53c876 detected
ncr53c8xx: at PCI bus 1, device 9, function 1
ncr53c8xx: 53c876 detected
ncr53c876-0:
Use SCSI emulation instead of ATAPI for the tape device. Also make sure
your mt is >= 0.5.
[tim@abit tim]# mt -v
mt-st v. 0.5b
[tim@abit linux]# dump -v
dump 0.4b
[tim@abit linux]# restore -v
restore 0.4b17
[dmesg exerpts - tape is /dev/st0]
...
hdd: HP COLORADO 20GB, ATAPI TAPE drive
...
Use SCSI emulation instead of ATAPI for the tape device. Also make sure
your mt is = 0.5.
[tim@abit tim]# mt -v
mt-st v. 0.5b
[tim@abit linux]# dump -v
dump 0.4b
[tim@abit linux]# restore -v
restore 0.4b17
[dmesg exerpts - tape is /dev/st0]
...
hdd: HP COLORADO 20GB, ATAPI TAPE drive
...
> > Obvious question is, which compiler.
>
> I hadn't seen any locks, but (on a dual Pmmx 200) it started crawling
> right after the NIC module (tulip) was loaded. System load decided to
> skyrocket.
>
> Yadda... 2.2.19 with devfs patch.
> bicycle:~# gcc -v
> Reading specs from
David Lang wrote:
>
> watch the resonate heartbeat and see if it is getting lost in the network
> traffic (the resonate logs will show missing heartbeat packets). think
> seriously of setting the resonate stuff to run at a higher priority so
> that it doesn't get behind.
>
> depending on how
Obvious question is, which compiler.
I hadn't seen any locks, but (on a dual Pmmx 200) it started crawling
right after the NIC module (tulip) was loaded. System load decided to
skyrocket.
Yadda... 2.2.19 with devfs patch.
bicycle:~# gcc -v
Reading specs from
(2.2.19 + ide.2.2.19.04092001.patch)
--- drivers/block/hpt366.c Fri Apr 20 14:23:54 2001
+++ drivers/block/hpt366.new.c Fri Apr 27 16:30:13 2001
@@ -56,8 +56,11 @@
const char *bad_ata66_4[] = {
"IBM-DTLA-307075",
+ "IBM-DTLA-307060",
"IBM-DTLA-307045",
> mt : mt-st v. 0.4
Also mt-st < v0.5b were fairly broken especially with positioning.
rgds,
tim.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I've been running masquerading unchanged from 2.2.13, currently 2.2.19 as:
real IP +
masq. 192.168.1.NNN
DSL <-> gateway <-> switch <-> client 1
server <-> client 2
...
<-> client n
There
I've been running masquerading unchanged from 2.2.13, currently 2.2.19 as:
real IP +
masq. 192.168.1.NNN
DSL - gateway - switch - client 1
server - client 2
...
- client n
There was some
mt : mt-st v. 0.4
Also mt-st v0.5b were fairly broken especially with positioning.
rgds,
tim.
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
David Rees wrote:
> What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time?
Try 'hdparm -tT' with simultaneous /dev/hda3 and /dev/hdc3. This gives you
a baseline on the actual partitions involved.
rgds,
tim.
--
-
To unsubscribe from this list: send the line "unsubscribe
David Rees wrote:
What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time?
Try 'hdparm -tT' with simultaneous /dev/hda3 and /dev/hdc3. This gives you
a baseline on the actual partitions involved.
rgds,
tim.
--
-
To unsubscribe from this list: send the line "unsubscribe
> > FrastTrack/100 Raid controller working. I finally found the ft.o driver
Did you try building it from source? Their docs say beta ft.o is RH 6.2-7.0
which would make me a bit nervous.
ftp://ftp.promise.com/Controllers/IDE/FastTrak100/Linux/LinuxBETA/
--
-
To unsubscribe from this list:
FrastTrack/100 Raid controller working. I finally found the ft.o driver
Did you try building it from source? Their docs say beta ft.o is RH 6.2-7.0
which would make me a bit nervous.
ftp://ftp.promise.com/Controllers/IDE/FastTrak100/Linux/LinuxBETA/
--
-
To unsubscribe from this list: send
> I am afraid that I do not know how to change my partition type. I can confirm.
>however, that the BIOS is set to Auto / LBA and that BIOS confirms UDMA 5 is set (and
>cannot be set unless the correct cabling is detected).
[tim@abit tim]# fdisk /dev/hdc
Command (m for help): t
Partition
I am afraid that I do not know how to change my partition type. I can confirm.
however, that the BIOS is set to Auto / LBA and that BIOS confirms UDMA 5 is set (and
cannot be set unless the correct cabling is detected).
[tim@abit tim]# fdisk /dev/hdc
Command (m for help): t
Partition number
>Device BootStart EndBlocks Id System
> /dev/hda1 * 1 932 7486258+ b Win95 FAT32
Try changing to 'c' (fat32+LBA) and check BIOS settings (s/b AUTO or USER,
and LBA).
rgds,
tim.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> >Device BootStart EndBlocks Id System
> > /dev/hda1 * 1 932 7486258+ b Win95 FAT32
> > ...
> > I also ran hdparm -tT /dev/hda1:
> >
> > Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
> > Timing buffered disk reads: 64 MB in 4.35
Device BootStart EndBlocks Id System
/dev/hda1 * 1 932 7486258+ b Win95 FAT32
...
I also ran hdparm -tT /dev/hda1:
Timing buffer-cache reads: 128 MB in 1.28 seconds =100.00 MB/sec
Timing buffered disk reads: 64 MB in 4.35 seconds =
Device BootStart EndBlocks Id System
/dev/hda1 * 1 932 7486258+ b Win95 FAT32
Try changing to 'c' (fat32+LBA) and check BIOS settings (s/b AUTO or USER,
and LBA).
rgds,
tim.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Mark Hahn wrote:
>
> > > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2),
>which has a PIIX4 controller.
> > > > ...
> > > > My problem is that (according to hdparm -t), I never get a better transfer
>rate than approximately 15.8 Mb/sec
> > >
> > > 15MB/s for
Jeremy Jackson wrote:
>
> Tim Moore wrote:
> > 15MB/s for hdparm is about right.
>
> Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of
>data reads from
> disk surface. Only if you read *only* data that is alread in harddr
> You should be able to get about 30 MB/s at the start of the disk (zone 0) according
>to IBM's datasheet at
>
> http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf
>
> so if you were testing say /dev/hda1 which is at the start of the disk it should be
>faster.
"should be"
[EMAIL PROTECTED] wrote:
> I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which
>has a PIIX4 controller.
> ...
> My problem is that (according to hdparm -t), I never get a better transfer rate than
>approximately 15.8 Mb/sec. I achieve this when DMA is enabled, -
[EMAIL PROTECTED] wrote:
I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which
has a PIIX4 controller.
...
My problem is that (according to hdparm -t), I never get a better transfer rate than
approximately 15.8 Mb/sec. I achieve this when DMA is enabled, -
You should be able to get about 30 MB/s at the start of the disk (zone 0) according
to IBM's datasheet at
http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf
so if you were testing say /dev/hda1 which is at the start of the disk it should be
faster.
"should be" is yes
Jeremy Jackson wrote:
Tim Moore wrote:
15MB/s for hdparm is about right.
Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of
data reads from
disk surface. Only if you read *only* data that is alread in harddrive's cache will
you get a sp
Mark Hahn wrote:
I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2),
which has a PIIX4 controller.
...
My problem is that (according to hdparm -t), I never get a better transfer
rate than approximately 15.8 Mb/sec
15MB/s for hdparm is about right.
The patch works on 2.2.19pre17. The second machine (asus) has Uwe's patch modified
for 2.2. The
machine 'smp' is not patched.
rgds,
tim.
[tim@smp ~]# cat /proc/uptime ; cat /proc/stat | grep cpu ; yes > /dev/null & ; sleep
180 ; killall
yes ; cat /proc/uptime ; cat /proc/stat | grep cpu
[2]
> Same for 2.2.19p17
except that init_tasks is a 2.4 struc. Corrected as below.
rgds,
tim
--- 2.2.19pre17/fs/proc/array.c.old Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:35:36 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned
> At present the idle value in /proc/uptime is only the idle time for the first
> processor. With 2.4, processes seam "stickier" for my, and e.g "yes
> >/dev/null" on an otherwise idle machine can stay for a long time on one
> processor of my (intel) SMP machine. That way, the present output of
>
At present the idle value in /proc/uptime is only the idle time for the first
processor. With 2.4, processes seam "stickier" for my, and e.g "yes
/dev/null" on an otherwise idle machine can stay for a long time on one
processor of my (intel) SMP machine. That way, the present output of
Same for 2.2.19p17
except that init_tasks is a 2.4 struc. Corrected as below.
rgds,
tim
--- 2.2.19pre17/fs/proc/array.c.old Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:35:36 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned
The patch works on 2.2.19pre17. The second machine (asus) has Uwe's patch modified
for 2.2. The
machine 'smp' is not patched.
rgds,
tim.
[tim@smp ~]# cat /proc/uptime ; cat /proc/stat | grep cpu ; yes /dev/null ; sleep
180 ; killall
yes ; cat /proc/uptime ; cat /proc/stat | grep cpu
[2]
> The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon
Also try comp.os.linux.hardware.
BIOS
278/irq5
378/irq7
EPP 1.9
.config
---
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PNP=y
CONFIG_PNP_PARPORT=y
CONFIG_PRINTER=y
CONFIG_PRINTER_READBACK=y
kernal boot params
The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon
Also try comp.os.linux.hardware.
BIOS
278/irq5
378/irq7
EPP 1.9
.config
---
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PNP=y
CONFIG_PNP_PARPORT=y
CONFIG_PRINTER=y
CONFIG_PRINTER_READBACK=y
kernal boot params
> i had a small problem with a program i was running
> which got stuck in a loop allocing memory by the time i
> found out it was doing it these were appearing
>
> VM: do_try_to_free_pages failed for ypbind...
> ...
> etc.. etc.. for many more processes
> then it all ended in a hangup
Patch to
i had a small problem with a program i was running
which got stuck in a loop allocing memory by the time i
found out it was doing it these were appearing
VM: do_try_to_free_pages failed for ypbind...
...
etc.. etc.. for many more processes
then it all ended in a hangup
Patch to
Tom Sightler wrote:
> ...
> For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of
> storage, and elect to export that entire amount as a single NFS mount, and
> then use that storage to allow several Linux boxes to share 100GB
> (admittedly temporary) files, will Linux handle
Tom Sightler wrote:
...
For example if we purchase a NetApp Filer, or EMC Celerra with 1TB of
storage, and elect to export that entire amount as a single NFS mount, and
then use that storage to allow several Linux boxes to share 100GB
(admittedly temporary) files, will Linux handle that, at
Interesting. This is a KA7 with all power management turned off in the
latest Abit BIOS.
> The kernel puts the timer back and life appears happy again
Ahhh. The kernel *is* god.
Alan Cox wrote:
>
> > Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer
> > configuration lost -
For no apparent reason:
...
Feb 26 00:15:50 abit xntpd[886]: synchronized to 192.6.38.127, stratum=1
Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer
configuration lost - probably a VIA686a.
Feb 26 00:19:52 abit kernel: probable hardware bug: restoring chip
configuration.
Feb 26
For no apparent reason:
...
Feb 26 00:15:50 abit xntpd[886]: synchronized to 192.6.38.127, stratum=1
Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer
configuration lost - probably a VIA686a.
Feb 26 00:19:52 abit kernel: probable hardware bug: restoring chip
configuration.
Feb 26
Interesting. This is a KA7 with all power management turned off in the
latest Abit BIOS.
The kernel puts the timer back and life appears happy again
Ahhh. The kernel *is* god.
Alan Cox wrote:
Feb 26 00:19:52 abit kernel: probable hardware bug: clock timer
configuration lost -
> for partitions not in the first 8gb of a harddisk, what
> should the c/h/s start and end value be ?
http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO.html
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
...
> It happens when dma is enabled by hdparm -d1 /dev/hda or when dma is
> enabled automatically by the kernel.
>
> I have an Abit kt7 mb with the kt133 chipset,Athlon 900 , 128MB mem,
> quantum fireball 20G disk, gcc 2-95-2 , glibc 2-2-1.
>
> There are no problems with dma disabled.
>
> I
...
It happens when dma is enabled by hdparm -d1 /dev/hda or when dma is
enabled automatically by the kernel.
I have an Abit kt7 mb with the kt133 chipset,Athlon 900 , 128MB mem,
quantum fireball 20G disk, gcc 2-95-2 , glibc 2-2-1.
There are no problems with dma disabled.
I was not
for partitions not in the first 8gb of a harddisk, what
should the c/h/s start and end value be ?
http://www.linuxdoc.org/HOWTO/Large-Disk-HOWTO.html
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
> I've enabled the higher performance features for my ATA drive by getting
> 2.2.17, applying Andre Hendrick's IDE patch, adding:
> append="idebus=66 ide0=ata66"
> to lilo.conf. I was told that Alan's patches from here:
> should be used. Is this true if I used Andre's patch? Is the warning
>
I've enabled the higher performance features for my ATA drive by getting
2.2.17, applying Andre Hendrick's IDE patch, adding:
append="idebus=66 ide0=ata66"
to lilo.conf. I was told that Alan's patches from here:
should be used. Is this true if I used Andre's patch? Is the warning
message
Is via82cxxx.c v3.17 a 2.4.x only patch or did I miss something else?
[tim@asus linux]# ../build
dep ===
clean ===
bzImage ===
via82cxxx.c:108: `PCI_DEVICE_ID_VIA_8233_0' undeclared here (not in a
function)
via82cxxx.c:108: initializer
Is via82cxxx.c v3.17 a 2.4.x only patch or did I miss something else?
[tim@asus linux]# ../build
dep ===
clean ===
bzImage ===
via82cxxx.c:108: `PCI_DEVICE_ID_VIA_8233_0' undeclared here (not in a
function)
via82cxxx.c:108: initializer
> What version of the raidtools to I need for 2.2.18 software raid?
> Documentation/md.txt has a non-functional URL in it.
0.90
http://www.kernel.org/pub/linux/kernel/people/mingo/raid-patches/
http://www.kernel.org/pub/linux/daemons/raid/alpha/
--
| Work like you don't need the money.
What version of the raidtools to I need for 2.2.18 software raid?
Documentation/md.txt has a non-functional URL in it.
0.90
http://www.kernel.org/pub/linux/kernel/people/mingo/raid-patches/
http://www.kernel.org/pub/linux/daemons/raid/alpha/
--
| Work like you don't need the money.
72 matches
Mail list logo
