public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andries.Brouwer@cwi.nl
To: dalecki@evision-ventures.com, torvalds@transmeta.com
Cc: linux-kernel@vger.kernel.org
Subject: IDE cleanup eats disks
Date: Sun, 3 Mar 2002 22:02:15 GMT	[thread overview]
Message-ID: <UTC200203032202.WAA145534.aeb@cwi.nl> (raw)

On one of my machines I lose two disk drives with
2.5.6-pre2 that still were present with 2.5.6-pre1.
Looking why, I see that the cleanup of ide-pci.c
cleaned them away.

This is not necessarily bad, leaving things as they are is
certainly an option, although maybe I prefer the old situation,
but I just report the fact that the cleanup changes behaviour.

In this case I had two disks hanging off a HPT366 card
but no CONFIG_BLK_DEV_HPT366 selected. Until now this
worked: the values {PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT366}
were always compiled in. On the other hand, 2.5.6-pre2 only
knows about them when CONFIG_BLK_DEV_HPT366 is selected,
so does not recognize the card and does not see the disks.

As a check I changed 2.5.6-pre2 by

 #ifdef CONFIG_BLK_DEV_HPT366
        {PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT366, pci_init_hpt366, ...
+#else
+       {PCI_VENDOR_ID_TTI, PCI_DEVICE_ID_TTI_HPT366, NULL, NULL,
+        IDE_NO_DRIVER, NULL, {{0x00,0x00,0x00}, {0x00,0x00,0x00}},
+	 OFF_BOARD, 240, ATA_F_IRQ | ATA_F_HPTHACK },
 #endif

and indeed, this brings the drives back to life.

Andries


[Of course this is not a suggested patch. The same comment applies
to all devices, not just HPT366.]
[Thus, the old situation was that if one did not use DMA then all
just worked, and no special chipset code was required. The new
situation is that one has to select DMA before encountering the
CONFIG_BLK_DEV_HPT366 option.]

             reply	other threads:[~2002-03-03 22:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-03 22:02 Andries.Brouwer [this message]
2002-03-04 10:44 ` IDE cleanup eats disks Martin Dalecki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=UTC200203032202.WAA145534.aeb@cwi.nl \
    --to=andries.brouwer@cwi.nl \
    --cc=dalecki@evision-ventures.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox