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 messag
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.
---
e-
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 2.2/2.
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 /dev/hd_your_ibm
> "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* controll
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
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 m
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 pleas
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 o
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. I
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 probl
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 c
> > 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 prob
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 forma
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 udma3
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
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* contr
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 block
> @@ -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 && bl
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 req
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 unsubs
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 ifde
> > 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 h
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 ((driv
> 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 supp
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
f
> ./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 unsubscri
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 >= 2K
34 matches
Mail list logo
