Re: "ide=reverse" do we still need this?

2008-02-13 Thread Rene Herman

On 13-02-08 13:06, Rene Herman wrote:

On 13-02-08 05:44, Greg KH wrote:


While details escape me somewhat again at the monment, a few months ago
I was playing around with a PCI Promise IDE controller and needed
ide=reverse to save me from having to switch disks around to still have
a bootable system.

Or some such. Not too clear anymore, but I remember it saved the day.


You couldn't just change the boot disk in grub?

Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable?


No. The thing is that you need these kinds of hacks while messing with 
old systems, building and stripping them, often in recovery type of 
situations.


As said (same as the other person I saw reacting) details of what was 
most decidedly needed last time around escape me at the moment, but 
ide=reverse is the kind of hack that saves one hours of unscrewing 
computer cases and switching disks around while building stuff, making 
quick tests, doing recovery...


If it must go for the greater architectural good, so be it, but it's the 
type of thing that's used specifically in the situations where you don't 
have stable, well arranged (or known!) setups to begin with.


Allow me to add that the demise of drivers/ide itself is an argument for 
just shooting the thing if it helps clean up the API. Next year when I'm 
messing with that Promise controller again, the machine might very well be 
running a kernel using PATA instead of IDE anyway...


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: "ide=reverse" do we still need this?

2008-02-13 Thread Rene Herman

On 13-02-08 13:16, Michael Ellerman wrote:


On Wed, 2008-02-13 at 13:06 +0100, Rene Herman wrote:

On 13-02-08 05:44, Greg KH wrote:


While details escape me somewhat again at the monment, a few months ago
I was playing around with a PCI Promise IDE controller and needed
ide=reverse to save me from having to switch disks around to still have
a bootable system.

Or some such. Not too clear anymore, but I remember it saved the day.

You couldn't just change the boot disk in grub?

Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable?
No. The thing is that you need these kinds of hacks while messing with old 
systems, building and stripping them, often in recovery type of situations.


As said (same as the other person I saw reacting) details of what was most 
decidedly needed last time around escape me at the moment, but ide=reverse 
is the kind of hack that saves one hours of unscrewing computer cases and 
switching disks around while building stuff, making quick tests, doing 
recovery...


If it must go for the greater architectural good, so be it, but it's the 
type of thing that's used specifically in the situations where you don't 
have stable, well arranged (or known!) setups to begin with.


I might be off the deep end, but isn't this what
Documentation/feature-removal-schedule.txt is for?


Documentation/feature-removal-schedule.txt is for asking/discussing whether 
or not features should be removed? No, I don't think so. It seems to be a 
schedule of when to remove features.


Rene.


-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: "ide=reverse" do we still need this?

2008-02-13 Thread Rene Herman

On 13-02-08 05:44, Greg KH wrote:


While details escape me somewhat again at the monment, a few months ago
I was playing around with a PCI Promise IDE controller and needed
ide=reverse to save me from having to switch disks around to still have
a bootable system.

Or some such. Not too clear anymore, but I remember it saved the day.


You couldn't just change the boot disk in grub?

Or use an initramfs and /dev/disk/by-id/ to keep any future moves stable?


No. The thing is that you need these kinds of hacks while messing with old 
systems, building and stripping them, often in recovery type of situations.


As said (same as the other person I saw reacting) details of what was most 
decidedly needed last time around escape me at the moment, but ide=reverse 
is the kind of hack that saves one hours of unscrewing computer cases and 
switching disks around while building stuff, making quick tests, doing 
recovery...


If it must go for the greater architectural good, so be it, but it's the 
type of thing that's used specifically in the situations where you don't 
have stable, well arranged (or known!) setups to begin with.


Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: "ide=reverse" do we still need this?

2008-02-12 Thread Rene Herman

On 13-02-08 01:15, Greg KH wrote:


I'm reworking the pci device list logic (we currently keep all PCI
devices in 2 lists, which isn't the nicest, we should be able to get
away with only 1 list.)

The only bother I've found so far is the pci_get_device_reverse()
function, it's used in 2 places, IDE and the calgary driver.

I'm curious if we really still support the ide=reverse option?  It's a
config option that I don't think the distros still enable (SuSE does
not).  Is this still needed these days?

In digging, we changed this option in 2.2.x from being called
"pci=reverse" and no one else seems to miss it.

Any thoughts?


While details escape me somewhat again at the monment, a few months ago I 
was playing around with a PCI Promise IDE controller and needed ide=reverse 
to save me from having to switch disks around to still have a bootable system.


Or some such. Not too clear anymore, but I remember it saved the day.

Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: size of git repository (was Re: [BUG] New Kernel Bugs)

2007-11-18 Thread Rene Herman

On 18-11-07 15:35, James Bottomley wrote:


clean-cg? But failure to run "git repack -a -d" every once in a while?


Actually, the best command is

git gc

which does a repack (into a single pack file rather than an incremenal), 
and then removes all the objects now in the pack.  If, like me, you work 
on temporary branches which you keep rebasing, you can add a --prune to 
gc which will erase all unreferenced objects as it packs (use this one 
with care.  I usually never use it but run a git prune -n just to see 
what would be removed, and then run git prune separately if it looks OK).


Thanks for the comment. That managed to indeed shave a few extra bytes off 
my already "repack -a -d" packed repo still.


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: size of git repository (was Re: [BUG] New Kernel Bugs)

2007-11-18 Thread Rene Herman

On 18-11-07 13:44, Pavel Machek wrote:


On Tue 2007-11-13 12:50:08, Mark Lord wrote:


It's a 540MByte download over a slow link for everyone 
else.


Hmmm, clean-cg is 7.7G on my machine, and yes I tried
git-prune-packed. What am I doing wrong?


clean-cg? But failure to run "git repack -a -d" every once in a while?

Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] [BUG] New Kernel Bugs

2007-11-15 Thread Rene Herman

On 15-11-07 14:00, Jörn Engel wrote:

And even without mails being held hostage for weeks, every single 
moderation mail is annoying.  Like the one I'm sure to receive after 
sending this out.


Certainly. Upto this thread I wasn't actually aware the list was doing that. 
While it might be informative once, getting it each time quickly gets old. 
Don't know if mailman can do anything like it but I'd suggest anyone running 
a non-subscriber-moderation list configure it to send such messages at most 
once a  per address or some such. And just disable the message 
if it cannot do that.


Fortunately, alsa-devel is (almost) no longer such a list anyway as it's 
moving to vger. Hurrah. David -- thanks.


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] [BUG] New Kernel Bugs

2007-11-15 Thread Rene Herman

On 15-11-07 13:02, Bron Gondwana wrote:


I get the same information from both project websites: "moderated for
non-members, public archives" - no way of knowing that ALSA will accept
me informing them of something they would be interested without
committing to reading or bit-bucketing their list.


Can you please just shelve this crap? You have a way of knowing that "ALSA 
will accept you" and that is knowing or assuming that the ALSA project 
doesn't consist of drooling retards.


When a project list goes to the difficulty of moderating non-subscribers it 
has made the explicit choice to _not_ become subscriber only. Then refusing 
valid non-subscribers after all makes no sense whatsoever. I'm sorry you got 
your feelings hurt by that other list but it was no doubt an accident; take 
it up with them.


Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Moderated list

2007-11-14 Thread Rene Herman

On 15-11-07 00:23, David Miller wrote:


From: Takashi Iwai <[EMAIL PROTECTED]>



BTW, I also prefer keeping the name [EMAIL PROTECTED]  It's been so.


That's fine with me, I've changed it [EMAIL PROTECTED]


Great, thanks. Jaroslav -- given that this list won't need moderation I'd 
consider it the main/only alsa-devel. The alsa-devel subscriber database was 
cleansed only a couple of months ago when moving from sourceforge so it 
should now be okay to just transfer all subscriptions.


Or maybe you're already moving things; mailman.alsa-project.org seems to be 
down at least


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] [BUG] New Kernel Bugs

2007-11-14 Thread Rene Herman

On 15-11-07 05:16, Bron Gondwana wrote:


Totally unrelated - I sent something to the kolab mailing list a couple


[ ... ]

I'm sure if I had something that I considered worth informing the ALSA 
project of, I'd be wary of spending the same effort writing a good post
knowing it may be dropped in between the by a list moderator just 
selecing all and bouncing them.


Totally unrelated indeed so why are spouting crap? If the kohab list has a 
problem take it up with them but keep ALSA out of it. alsa-devel has only 
ever moderated out spam -- nothing else.


ene
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] [BUG] New Kernel Bugs

2007-11-14 Thread Rene Herman

On 14-11-07 13:01, David Miller wrote:


From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)


The fact that it farts at me every time I post to this thread.


See?  I got another one and I have received at least 10 of the
following over the past 2 days.


Nah, in this case you are not even getting them to not being a non-subcriber 
but due to too many CCs. I got one as well. That just needs to be disabled, 
does not have anything to do with non-subscribers (and you're in the white 
list) but is just a retarted bit of list configuration...


(no, I can't personally change it, needs Jaroslav Kysela)

Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] [BUG] New Kernel Bugs

2007-11-14 Thread Rene Herman

On 14-11-07 12:56, David Miller wrote:


From: Rene Herman <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 12:46:24 +0100

[EMAIL PROTECTED] is not subscriber-only. Same as that arm list, 
it's _moderated_ for non-subscribers and given that I and other moderators 
have been doing our best to moderate quickly (I tend to stay logged in to 
the moderation interface all day for example) what specifically bugged the 
crap out of you? It's not something a poster needs to concern himself with.


The fact that it farts at me every time I post to this thread.  That's
rude and annoying.


It certainly is. I only experienced that now due to the "too many recipients 
to message" moderation notice that I got from my own message.


Jaroslav -- please disable that junk or if possible, make it a "at most once 
per address per month" thing or somesuch. This is complete crap.


Also for alsa-devel the moderators tend to add any valid non-subcribers to 
a whitelist after landing in the queue the first time meaning even a delay 
is just a one-time thing normally. So what's the trouble? Basically, noone 
need even notice...


That sucks for new people taking part in the conversation.

There is no reason for moderation at all, it isn't necessary
for spam prevention and it does nothing but annoy new posters
and make work for the moderator.


Yes there is. It's necessary for lists that do not have the human and other 
resouces behind it that vger does. alsa-devel was drowning in spam and dying 
as a result back when it was at sourceforge. Upon moving, my preference was 
to ask the lists to be hosted at vger but given that (it seems) Jaroslav 
wanted to keep them locally, moderation was very necessary. I moderate out 
quite a bit of spam every day.


vger is doing an amazing job at spam filtering -- if it's an option to move 
to vger, than sure, no need. But otherwise, the "no need" needs a list admin 
with enough bandwidth and skill.


As to the "new people": it's not optimal, but (upto this thread I'll admit 
-- I woke up to a huge number of posts in the queue) it's not been a _real_ 
problem. alsa-devel is not high-volume enough for it to be.


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Moderated list (Was: Re: [BUG] New Kernel Bugs)

2007-11-14 Thread Rene Herman

On 14-11-07 09:25, Takashi Iwai wrote:


At Wed, 14 Nov 2007 04:01:31 -0800 (PST),
David Miller wrote:

From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)


The fact that it farts at me every time I post to this thread.

See?  I got another one and I have received at least 10 of the
following over the past 2 days.

That's rediculious.

And because a human adds the whitelist this is always going to
happen to someone when they start posting to the alsa list for
the first time.


... if you give too many recipients in your post.  That is often
really annoying thing to me, together with keeping the unrelated
subject line ;)

I personally don't care whether it's a moderated or open list.
We chose it simply due to too bad S/N ratio at that time.  So, if the
current list annoys your or many others and the list management on
vger is so good, it'd be basically a good move, of course.  I'll
appreciate it.

The only confusion would be the change of ML address, but we can do it
slowly, too.


I'd love the lists at vger. Amazing spam-filtering. I'd like to request the 
name [EMAIL PROTECTED] (and [EMAIL PROTECTED] if at all 
possible so we can open that one up as well) though.


There wouldn't need to be a forced ML address change if Jaroslov would then 
just rewrite alsa-{devel,[EMAIL PROTECTED] to vger.kernel.org same as 
he did for alsa-devel and does for alsa-user to @lists.sf.net.


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [alsa-devel] [BUG] New Kernel Bugs

2007-11-14 Thread Rene Herman

On 14-11-07 11:07, David Miller wrote:

Added Jaroslav and Takashi to the already extensive CC


From: Russell King <[EMAIL PROTECTED]>



So, when are you creating a replacement alsa-devel mailing list on
vger?  That's also subscribers-only.


The operative term is "alternative" rather than "replacement".
Perhaps this misunderstanding is what you're so upset about.

And yes, that alsa list bugs the crap out of me too.  I'm more than
happy to provide an alternative for that one as well.


[EMAIL PROTECTED] is not subscriber-only. Same as that arm list, 
it's _moderated_ for non-subscribers and given that I and other moderators 
have been doing our best to moderate quickly (I tend to stay logged in to 
the moderation interface all day for example) what specifically bugged the 
crap out of you? It's not something a poster needs to concern himself with.


Also for alsa-devel the moderators tend to add any valid non-subcribers to 
a whitelist after landing in the queue the first time meaning even a delay 
is just a one-time thing normally. So what's the trouble? Basically, noone 
need even notice...



In fact, *poof*, there it is, [EMAIL PROTECTED] is there and
available for anyone who wants to use it.


Not that I think that moving alsa-devel over to vger wouldn't be a good idea 
mind you; when the list moved from sourceforge, asking you to host it was my 
preferred option. I do somewhat suspect that Jaroslav would like to keep the 
alsa-devel@ name (and I'd like to ask you to then also host alsa-user@) and 
would then rewrite mail to those lists @alsa-project.org to vger.


But what is the problem you speak of with the alsa-devel list? While I would 
not mind loosing it, moderation hasn't been overly laborious and I'm not 
aware of any serious problems.


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problems with IDE on linux 2.6.22.X

2007-08-30 Thread Rene Herman

On 08/30/2007 11:16 PM, Greg Freemyer wrote:


On 8/30/07, Rene Herman <[EMAIL PROTECTED]> wrote:



Well -- the world where ATA, SCSI, USB, Firewire and what have you are
low-level drivers to a unifying storage layer is under non too obscure
definitions sort of not non-wonderful...



USB / Firewire / FC / iSCSI are all SCSI transports and fit within the
SCSI subsystem by design.

ie. Just like ethernet, DSL, T-1, etc can all carry IP traffic with no
conceptual conflict, many media by design carry SCSI traffic.

The PATA and SATA physical layer typically carry ATA commands and
having them tied into the SCSI stack is an aberration that I hope will
be eliminated some day.

ATAPI is an exception.  Not sure where that would end up in a perfect world.


As said, if you make a bit of an effort to view the former SCSI stack as a 
unified storage midlayer the abberation becomes less abberational (if that's 
a word).


Real SCSI, the other SCSI transports and ATAPI would just use more of the 
common mid-layer than P/SATA would. I'd expect the way forward would be to 
just refactor things until someone notices that drivers/scsi is the wrong 
place for sd.c and sr.c and moves them to drivers/block or whereever.


Practically, the PATA driver gives me (almost) the same throughput as the 
old IDE driver does, and given that I need the former SCSI stack _anyway_ 
for my external USB harddrive, I don't see a pressing need to carry along 
yet another storage stack for my harddrive.


Rene.


-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problems with IDE on linux 2.6.22.X

2007-08-30 Thread Rene Herman

On 08/30/2007 09:31 PM, Jan Engelhardt wrote:


On Aug 28 2007 19:05, Rene Herman wrote:



Sheesh. How could anyone _not_ understand you need SCSI CD-ROM support
for your IDE DVD-RW drive...


Welcome to the wonderful world of SCSIfying ATA. (Don't talk about ATAPI,
USB/Firewire, it's a different matter.)


Well -- the world where ATA, SCSI, USB, Firewire and what have you are 
low-level drivers to a unifying storage layer is under non too obscure 
definitions sort of not non-wonderful...


Admittedly, the unifying layer is a little SCSI inspired but so is a lot of 
the hardware. As long as the users (the humans) resist SCSI inspiration, it 
should be safe.


Rene
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problems with IDE on linux 2.6.22.X

2007-08-28 Thread Rene Herman

On 08/28/2007 02:44 AM, José Luis Patiño Andrés wrote:


Okay Rene, I activated SCSI CD-ROM support in kernel config and now all
works again. It's strange, because I never used this option to get my DVD
device on.


Sheesh. How could anyone _not_ understand you need SCSI CD-ROM support for 
your IDE DVD-RW drive...


Rene "Sigh" Herman

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problems with IDE on linux 2.6.22.X

2007-08-22 Thread Rene Herman

On 08/22/2007 06:23 PM, Lennart Sorensen wrote:


On Wed, Aug 22, 2007 at 05:48:52PM +0200, Rene Herman wrote:


He has a SATA harddrive and an IDE DVD drive. When he compiles with 
CONFIG_ATA_PIIX (a driver which advertises both SATA and PATA in its 
description) his drive works, his DVD does not. Is that not the correct 
driver? Does he need something else? How does he get his DVD to work?


Well of course the DVD should show up as /dev/sr0 or scd0 with the new
driver, not the /dev/hd? name.  And scsi cdrom support is required too.


Obviously. Looking back through the report, him having SCSI CD-ROM support 
wasn't actually explicit so that might in fact be the problem but his 
self-compiled 2.6.20.15 worked and a 2.6.22 based Open SuSE Live CD does not 
(and he does have SCSI disk support, which suggests he will've likely also 
have thought of SCSI CD-ROM support) so it does not seem to be.


José: do you have SCSI CD-ROM support compiled in? What are the ATA/SCSI 
related messages in the output of "dmesg" when you compile with the 
CONFIG_ATA_PIIX driver, SCSI disk and SCSI CD-ROM support (and nothing from 
the old IDE menu)?


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problems with IDE on linux 2.6.22.X

2007-08-22 Thread Rene Herman

On 08/22/2007 01:23 PM, Alan Cox wrote:

The old SATA driver available from the IDE menu also does not support your 
chip, so I don't believe there are any workarounds -- you'll need the issue 
fixed.


What issue ?

From the report its quite simple - enable the correct CONFIG_ATA based
drivers and it should all work fine.


He has a SATA harddrive and an IDE DVD drive. When he compiles with 
CONFIG_ATA_PIIX (a driver which advertises both SATA and PATA in its 
description) his drive works, his DVD does not. Is that not the correct 
driver? Does he need something else? How does he get his DVD to work?


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problems with IDE on linux 2.6.22.X

2007-08-21 Thread Rene Herman

On 08/22/2007 03:39 AM, José Luis Patiño Andrés wrote:


You have a SATA harddrive (Hitachi Travelstar 5K100 100GB SATA/2.5") and an
IDE (also known as PATA) DVD drive (LG GMA-4082N). That is, your disk
should be driven by the:

"Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support"

under the "Serial ATA (prod) and Parallel ATA (experimental) drivers" menu,
and it seems this driver should also take care of your DVD. Not sure from
your report what you are using -- first try with only that driver, and
nothing from the old "ATA/ATAPI/MFM/RLL support" menu selected.

In that situation, your harddrive works, but your DVD does not?


Okay, now it's tested as you said. In fact, in this way with only the SATA 
drivers activated and ATA/ATAPI support completely unselected, my HDD works 
but my DVD not.


Okay. Jeff, Alan -- 2.6.20.15 apparently working. A few weeks ago there was 
another report of a DVD drive failing detection on pata_amd (my CD and DVD 
drives work fine on pata_amd). Did some ATAPI timeouts change or something?


He's using:

00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial 
ATA Storage Controller IDE (rev 02) (prog-if 80 [Master])



And so...


If so, this should be fixed in the driver, but to get things working I
believe you may try with both the above driver for your harddisk and the
old IDE driver for the DVD:

<*>   Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
<*> Include IDE/ATAPI CDROM support (NEW)
[*] PCI IDE chipset support
[*] Generic PCI bus-master DMA support
<*>   Intel PIIXn chipsets support


Checked.


(do not select IDE/ATA-2 disk support)


Unselected.

Now, I have this kernel panic:
###
#VFS: cannot open root device "sda3" or unknown-block (0,0)
#Please, append a correct "root=" boot option; here are the available 
#partitions:

#1600 4194302 hdc driver: ide-cdrom


Okay, makes sense, seems the new driver simply can't grab the SATA part 
anymore when the old driver already's got the IDE part -- I wasn't sure 
about that (not a SATA user myself -- just noticed your report due to 
noticing that previous one due to pata_amd...).


The old SATA driver available from the IDE menu also does not support your 
chip, so I don't believe there are any workarounds -- you'll need the issue 
fixed.


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html