Because I was not prepared for the sudden release!
Nor is the TIME Solution that is in final testing.
On Fri, 5 Jan 2001, Hakan Lennestal wrote:
>
> 2.4.0 and still no IBM DTLA drives in the hpt366 bad_ata66_4 list
> (or udma 66 disabled by default in any other way).
>
> /Håkan
>
> In
2.4.0 and still no IBM DTLA drives in the hpt366 bad_ata66_4 list
(or udma 66 disabled by default in any other way).
/Håkan
In message <[EMAIL PROTECTED]>, David Woodhouse writes:
>
> The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
---
I've been using a maxtor udma/66 13.6GB drive on the hpt366 for over a
year now with no problems whatsoever... even in udma/66 mode (also with
several different BIOS revisions). I have not however, ever been able
to get a cdrom to work on this controller either in windows 98/NT or in
linux
David Woodhouse wrote:
>
> The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
I'm using this drive with my BP6 without any problems.
But to have stable system I would suggest to not use UDMA4 mode
if you are stressing you harddrive to much.
Use UDMA3 (hdparm -X67
David Woodhouse wrote:
The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
I'm using this drive with my BP6 without any problems.
But to have stable system I would suggest to not use UDMA4 mode
if you are stressing you harddrive to much.
Use UDMA3 (hdparm -X67
I've been using a maxtor udma/66 13.6GB drive on the hpt366 for over a
year now with no problems whatsoever... even in udma/66 mode (also with
several different BIOS revisions). I have not however, ever been able
to get a cdrom to work on this controller either in windows 98/NT or in
linux
> "Hakan" == Hakan Lennestal <[EMAIL PROTECTED]> writes:
Hakan> Yes, the problem is the hpt366 (or the sw), not the IBM drives.
Hakan> The IBM drives seem to work well with udma3 on the hpt but not
Hakan> with udma4 or higher.
Is this specific to the 366? My DTLAs on a 370 are working like
On Tue, 2 Jan 2001, Hakan Lennestal wrote:
> > The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
>
> I second this !
> Until the hpt-problem is solved (if it ever will be)
> we really need the IBM DTLA drives in the bad-list.
> This configuration (IBM DTLA disks on hpt3*
On Tue, Jan 02 2001, Dan Hollis wrote:
> On Tue, 2 Jan 2001, Jens Axboe wrote:
> > On Tue, Jan 02 2001, Dan Hollis wrote:
> > > Also, using CDROM on hpt366 is recipe for disaster...
> > ATAPI in general actually, and as I understand it only with DMA.
>
> Nope I can blow it up with PIO also...
On Tue, 2 Jan 2001, Linus Torvalds wrote:
> Does the Maxtor and/or CDROM problems have anything to do with udma66? Ie
> if you can test, can you please check whether it's ok when they are added
> to the blacklists (or if udma66 is just disabled by default)?
Once I resend you the patches I have
On Tue, 2 Jan 2001, Jens Axboe wrote:
> On Tue, Jan 02 2001, Dan Hollis wrote:
> > Also, using CDROM on hpt366 is recipe for disaster...
> ATAPI in general actually, and as I understand it only with DMA.
Nope I can blow it up with PIO also...
-Dan
-
To unsubscribe from this list: send the line
On Tue, 2 Jan 2001, Linus Torvalds wrote:
> On Tue, 2 Jan 2001, Dan Hollis wrote:
> > Too bad Maxtor is still broken with hpt366...
> > Also, using CDROM on hpt366 is recipe for disaster...
> Does the Maxtor and/or CDROM problems have anything to do with udma66? Ie
> if you can test, can you
On Tue, Jan 02 2001, Dan Hollis wrote:
> Also, using CDROM on hpt366 is recipe for disaster...
ATAPI in general actually, and as I understand it only with DMA.
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Tue, 2 Jan 2001, Dan Hollis wrote:
> On Tue, 2 Jan 2001, David Woodhouse wrote:
> > It's a combination of chipset and drive that causes the problems. I've
> > been using ata66 with the same controller on a different drive
> > (FUJITSU MPE3136AT) for some time now, and it's been rock solid.
On Tue, 2 Jan 2001, David Woodhouse wrote:
> It's a combination of chipset and drive that causes the problems. I've
> been using ata66 with the same controller on a different drive
> (FUJITSU MPE3136AT) for some time now, and it's been rock solid. It's only
> the IBM DTLA drive that's been a
On Tue, 2 Jan 2001, Linus Torvalds wrote:
> So why are the IBM drives picked on? I thought this was a hpt366 problem,
> and possibly has only shown up with IBM drives so far.
>
> It sounds like the proper fix would be to not enable ata66 by default.
It's a combination of chipset and drive that
> > It sounds like the proper fix would be to not enable ata66 by default.
>
> LT,
>
> This is one of the evolution timing issues that both the drive guys and
> the chipset guys point fingers, while both attempt to fix the problem in
> their BIOS/Diskware.
Then lets default to ATA33 on the
On Tue, 2 Jan 2001, Linus Torvalds wrote:
>
>
> On Tue, 2 Jan 2001, Hakan Lennestal wrote:
>
> > In message <[EMAIL PROTECTED]>, David Woodhouse writes:
> > >
> > > The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
> >
> > I second this !
> > Until the hpt-problem is solved
[EMAIL PROTECTED] (Alan Cox) wrote on 01.01.01 in
<[EMAIL PROTECTED]>:
> > ./drivers/ide/ide-cd.c
> > ./drivers/ide/ide-cd.h
> >
> > Adds ATAPI DVD-RAM native read/write mode for any FS.
>
> Interesting to say the least. But..
>
> > mke2fs -b 2048 /dev/hdc
> > You must
In message <[EMAIL PROTECTED]>, L
inus Torvalds writes:
> So why are the IBM drives picked on? I thought this was a hpt366 problem,
> and possibly has only shown up with IBM drives so far.
Yes, the problem is the hpt366 (or the sw), not the IBM drives.
The IBM drives seem to work well with
On Tue, 2 Jan 2001, Hakan Lennestal wrote:
> In message <[EMAIL PROTECTED]>, David Woodhouse writes:
> >
> > The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
>
> I second this !
> Until the hpt-problem is solved (if it ever will be)
> we really need the IBM DTLA drives in
In message <[EMAIL PROTECTED]>, David Woodhouse writes:
>
> The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
I second this !
Until the hpt-problem is solved (if it ever will be)
we really need the IBM DTLA drives in the bad-list.
This configuration (IBM DTLA disks on hpt3*
The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Jan 01 2001, Alan Cox wrote:
> > for FAT etc when reading. Writing is a bit more difficult, as that
> > then turns out to generate a read before we can commit a dirty
> > block. IMO, this type of thing does not belong in the drivers --
> > we should _never_ receive request for < hard
On Mon, Jan 01 2001, Alan Cox wrote:
for FAT etc when reading. Writing is a bit more difficult, as that
then turns out to generate a read before we can commit a dirty
block. IMO, this type of thing does not belong in the drivers --
we should _never_ receive request for hard block size.
The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Tue, 2 Jan 2001, Hakan Lennestal wrote:
In message [EMAIL PROTECTED], David Woodhouse writes:
The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
I second this !
Until the hpt-problem is solved (if it ever will be)
we really need the IBM DTLA drives in the bad-list.
[EMAIL PROTECTED] (Alan Cox) wrote on 01.01.01 in
[EMAIL PROTECTED]:
./drivers/ide/ide-cd.c
./drivers/ide/ide-cd.h
Adds ATAPI DVD-RAM native read/write mode for any FS.
Interesting to say the least. But..
mke2fs -b 2048 /dev/hdc
You must format to 2048 size
On Tue, 2 Jan 2001, Linus Torvalds wrote:
On Tue, 2 Jan 2001, Hakan Lennestal wrote:
In message [EMAIL PROTECTED], David Woodhouse writes:
The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
I second this !
Until the hpt-problem is solved (if it ever will be)
On Tue, 2 Jan 2001, Linus Torvalds wrote:
So why are the IBM drives picked on? I thought this was a hpt366 problem,
and possibly has only shown up with IBM drives so far.
It sounds like the proper fix would be to not enable ata66 by default.
It's a combination of chipset and drive that
On Tue, 2 Jan 2001, David Woodhouse wrote:
It's a combination of chipset and drive that causes the problems. I've
been using ata66 with the same controller on a different drive
(FUJITSU MPE3136AT) for some time now, and it's been rock solid. It's only
the IBM DTLA drive that's been a problem
On Tue, 2 Jan 2001, Dan Hollis wrote:
On Tue, 2 Jan 2001, David Woodhouse wrote:
It's a combination of chipset and drive that causes the problems. I've
been using ata66 with the same controller on a different drive
(FUJITSU MPE3136AT) for some time now, and it's been rock solid. It's
On Tue, Jan 02 2001, Dan Hollis wrote:
Also, using CDROM on hpt366 is recipe for disaster...
ATAPI in general actually, and as I understand it only with DMA.
--
* Jens Axboe [EMAIL PROTECTED]
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Tue, 2 Jan 2001, Linus Torvalds wrote:
On Tue, 2 Jan 2001, Dan Hollis wrote:
Too bad Maxtor is still broken with hpt366...
Also, using CDROM on hpt366 is recipe for disaster...
Does the Maxtor and/or CDROM problems have anything to do with udma66? Ie
if you can test, can you please
On Tue, 2 Jan 2001, Jens Axboe wrote:
On Tue, Jan 02 2001, Dan Hollis wrote:
Also, using CDROM on hpt366 is recipe for disaster...
ATAPI in general actually, and as I understand it only with DMA.
Nope I can blow it up with PIO also...
-Dan
-
To unsubscribe from this list: send the line
On Tue, 2 Jan 2001, Linus Torvalds wrote:
Does the Maxtor and/or CDROM problems have anything to do with udma66? Ie
if you can test, can you please check whether it's ok when they are added
to the blacklists (or if udma66 is just disabled by default)?
Once I resend you the patches I have
On Tue, Jan 02 2001, Dan Hollis wrote:
On Tue, 2 Jan 2001, Jens Axboe wrote:
On Tue, Jan 02 2001, Dan Hollis wrote:
Also, using CDROM on hpt366 is recipe for disaster...
ATAPI in general actually, and as I understand it only with DMA.
Nope I can blow it up with PIO also...
Oh so ATAPI
On Tue, 2 Jan 2001, Hakan Lennestal wrote:
The IBM DTLA drives aren't in the hpt366 bad_ata66_4 list still.
I second this !
Until the hpt-problem is solved (if it ever will be)
we really need the IBM DTLA drives in the bad-list.
This configuration (IBM DTLA disks on hpt3* controller)
"Hakan" == Hakan Lennestal [EMAIL PROTECTED] writes:
Hakan Yes, the problem is the hpt366 (or the sw), not the IBM drives.
Hakan The IBM drives seem to work well with udma3 on the hpt but not
Hakan with udma4 or higher.
Is this specific to the 366? My DTLAs on a 370 are working like a
charm
> @@ -460,7 +460,7 @@
> opts.isvfat = sbi->options.isvfat;
> if (!parse_options((char *) data, , , , ,
> cvf_format, cvf_options)
> - || (blksize != 512 && blksize != 1024 && blksize != 2048))
> + || (blksize != 512 && blksize != 1024))
>
On Mon, Jan 01, 2001 at 05:34:01PM +, Alan Cox wrote:
> > for FAT etc when reading. Writing is a bit more difficult, as that
> > then turns out to generate a read before we can commit a dirty
> > block. IMO, this type of thing does not belong in the drivers --
> > we should _never_ receive
I screwed up on the patch for that one and have to find the correct one
that does the correct walk around on the mis matched standard problems.
This is my bad, sorry...back in 20 minutes...
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
-
To
On Mon, 1 Jan 2001, Andre Hedrick wrote:
> On Mon, 1 Jan 2001, Alan Cox wrote:
>
> > > > as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
> > >
> > > Exactly what it is designed to do, Ignore Validity Bits, because the whole
> > > damn messedup the rules between ATA-4 and ATA-6
> >
On Mon, 1 Jan 2001, Alan Cox wrote:
> > > as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
> >
> > Exactly what it is designed to do, Ignore Validity Bits, because the whole
> > damn messedup the rules between ATA-4 and ATA-6
>
> I think the question is more - so why not lose the
> > as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
>
> Exactly what it is designed to do, Ignore Validity Bits, because the whole
> damn messedup the rules between ATA-4 and ATA-6
I think the question is more - so why not lose the ifdef
-
To unsubscribe from this list: send the line
Because the people writing the SPEC screwed up.
The was a discussion to remove drive side detection and make it only host,
but since many chipset makers can not connect GPIO's for the 80 conductor
ribbonlet me walk you through the mess.
Bit 13 of word 93 is a capacitance decay test if the
Andre, what's the idea behind the following change:
--- linux-2.4.0-prerelease-pristine/drivers/ide/ide-features.c Mon Oct 16 12:21:40
2000
+++ linux-2.4.0-prerelease/drivers/ide/ide-features.c Sun Dec 31 21:53:17 2000
@@ -224,7 +224,7 @@
#ifndef CONFIG_IDEDMA_IVB
if
> for FAT etc when reading. Writing is a bit more difficult, as that
> then turns out to generate a read before we can commit a dirty
> block. IMO, this type of thing does not belong in the drivers --
> we should _never_ receive request for < hard block size.
Unfortunately someone ripped the
On Mon, Jan 01 2001, Alan Cox wrote:
> > mke2fs -b 2048 /dev/hdc
> > You must format to 2048 size blocks.
>
> FAT style FS doesnt support 2K blocks 8)
Then don't use FAT on DVD-RAM :-). ide-cd will already appropriately
cache a single block and dish out 512b sectors from that as needed
> ./drivers/ide/ide-cd.c
> ./drivers/ide/ide-cd.h
>
> Adds ATAPI DVD-RAM native read/write mode for any FS.
Interesting to say the least. But..
> mke2fs -b 2048 /dev/hdc
> You must format to 2048 size blocks.
FAT style FS doesnt support 2K blocks 8)
-
To
On Mon, Jan 01 2001, Andre Hedrick wrote:
> ide.2.4.0-prerelease.cd.1231.patch :
>
> ./drivers/ide/ide-cd.c
> ./drivers/ide/ide-cd.h
>
> Adds ATAPI DVD-RAM native read/write mode for any FS.
> mke2fs -b 2048 /dev/hdc
> You must format to 2048 size blocks.
Any >=
On Mon, Jan 01 2001, Andre Hedrick wrote:
ide.2.4.0-prerelease.cd.1231.patch :
./drivers/ide/ide-cd.c
./drivers/ide/ide-cd.h
Adds ATAPI DVD-RAM native read/write mode for any FS.
mke2fs -b 2048 /dev/hdc
You must format to 2048 size blocks.
Any = 2KB block
./drivers/ide/ide-cd.c
./drivers/ide/ide-cd.h
Adds ATAPI DVD-RAM native read/write mode for any FS.
Interesting to say the least. But..
mke2fs -b 2048 /dev/hdc
You must format to 2048 size blocks.
FAT style FS doesnt support 2K blocks 8)
-
To unsubscribe
On Mon, Jan 01 2001, Alan Cox wrote:
mke2fs -b 2048 /dev/hdc
You must format to 2048 size blocks.
FAT style FS doesnt support 2K blocks 8)
Then don't use FAT on DVD-RAM :-). ide-cd will already appropriately
cache a single block and dish out 512b sectors from that as needed
for
Andre, what's the idea behind the following change:
--- linux-2.4.0-prerelease-pristine/drivers/ide/ide-features.c Mon Oct 16 12:21:40
2000
+++ linux-2.4.0-prerelease/drivers/ide/ide-features.c Sun Dec 31 21:53:17 2000
@@ -224,7 +224,7 @@
#ifndef CONFIG_IDEDMA_IVB
if
Because the people writing the SPEC screwed up.
The was a discussion to remove drive side detection and make it only host,
but since many chipset makers can not connect GPIO's for the 80 conductor
ribbonlet me walk you through the mess.
Bit 13 of word 93 is a capacitance decay test if the
as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
Exactly what it is designed to do, Ignore Validity Bits, because the whole
damn messedup the rules between ATA-4 and ATA-6
I think the question is more - so why not lose the ifdef
-
To unsubscribe from this list: send the line
On Mon, 1 Jan 2001, Alan Cox wrote:
as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
Exactly what it is designed to do, Ignore Validity Bits, because the whole
damn messedup the rules between ATA-4 and ATA-6
I think the question is more - so why not lose the ifdef
-
On Mon, 1 Jan 2001, Andre Hedrick wrote:
On Mon, 1 Jan 2001, Alan Cox wrote:
as it apparently makes CONFIG_IDEDMA_IVB a complete no-op?
Exactly what it is designed to do, Ignore Validity Bits, because the whole
damn messedup the rules between ATA-4 and ATA-6
I think the
I screwed up on the patch for that one and have to find the correct one
that does the correct walk around on the mis matched standard problems.
This is my bad, sorry...back in 20 minutes...
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
-
To
On Mon, Jan 01, 2001 at 05:34:01PM +, Alan Cox wrote:
for FAT etc when reading. Writing is a bit more difficult, as that
then turns out to generate a read before we can commit a dirty
block. IMO, this type of thing does not belong in the drivers --
we should _never_ receive request
@@ -460,7 +460,7 @@
opts.isvfat = sbi-options.isvfat;
if (!parse_options((char *) data, fat, blksize, debug, opts,
cvf_format, cvf_options)
- || (blksize != 512 blksize != 1024 blksize != 2048))
+ || (blksize != 512 blksize != 1024))
ide.2.4.0-prerelease.1231.patch
./drivers/ide/cs5530.c
./drivers/ide/hpt366.c
./drivers/ide/ide-dma.c
./drivers/ide/ide-features.c
./drivers/ide/ide-pci.c
./drivers/ide/osb4.c
./drivers/ide/piix.c
./drivers/ide/sis5513.c
ide.2.4.0-prerelease.1231.patch
./drivers/ide/cs5530.c
./drivers/ide/hpt366.c
./drivers/ide/ide-dma.c
./drivers/ide/ide-features.c
./drivers/ide/ide-pci.c
./drivers/ide/osb4.c
./drivers/ide/piix.c
./drivers/ide/sis5513.c
64 matches
Mail list logo
