public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Trefzer <ctrefzer@gmx.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Herbert Rosmanith <kernel@wildsau.enemy.org>,
	linux-kernel@vger.kernel.org
Subject: Re: cdrom: a dirty CD can freeze your system
Date: Thu, 4 May 2006 19:54:41 +0200	[thread overview]
Message-ID: <20060504175441.GA2910@hermes.uziel.local> (raw)
In-Reply-To: <1146756522.22308.6.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 3352 bytes --]

On Thu, May 04, 2006 at 04:28:42PM +0100, Alan Cox wrote:
> 
> > Since you've been busy I didn't want to bother you, but now that you
> > mention your PATA efforts again, is there a git tree to pull from,
> > which contains code similar to that in the latest patches?
> 
> Not for the current code. The core stuff is mostly in the tree now and
> I'll try and push a patch some time today or tomorrow thats versus
> 2.6.17-rc and should match.
> 

Sounds great! I'll build new kernels for all my boxes as soon as I can
get a hold on said patch. At least it "felt" cleaner and I/O was a
little less of a handbrake using libata, so I'll go for it once again.

Just one more thing, I had to hack a little on Kconfig files to make the
"newer" promise driver available - if my memory doesn't fail me I sent a
patch, more like a RFC. Are some drivers intentionally left out of
Kbuild? I could not trigger any problem so far, using ata_piix on this
laptop, and pata_via / pata_pdc2027x on my desktop.

The only strangeness I had was some windoze firmware upgrade tool for my
ATAPI CDRW drive running in wine, poking on every sg device in
existence, thus triggering a freeze as it messed with the disks in some
wicked way. But since this was never intended to work in the first
place, I was happy with it working after simply deleting all sg devs
corresponding with disks. And I guess it is worth mentioning that the
SCSI IOCTLs in question are only accepted by the SCSI stack when the
process is run as root, so it's not exactly something anybody could try
on a machine he cannot already kill.  Attempts to run this as an
ordinary user would make the firmware tool get stuck with an all-empty
progress bar, and the wine processes were easily TERM-able.

If there's anything I might want to try out or you'd want to know, like
lspci output and such, please let me know. I'm not home right now, but
here goes for starters.


lspci excerpt:

00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])


lspci -vvvxxxn excerpt:

00:07.1 0101: 8086:7111 (rev 01) (prog-if 80)
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Region 4: I/O ports at 0860 [size=16]
00: 86 80 11 71 05 00 80 02 01 80 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 07 e3 07 e3 00 00 00 00 01 00 02 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00


This one has been working perfectly so far, on an ancient Dell Latitude
CPiA.


Kind regards,
Chris

[-- Attachment #2: Type: application/pgp-signature, Size: 829 bytes --]

  reply	other threads:[~2006-05-04 17:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-04 12:32 cdrom: a dirty CD can freeze your system Herbert Rosmanith
2006-05-04 12:45 ` Michael Tokarev
2006-05-04 12:56   ` Herbert Rosmanith
2006-05-04 14:41   ` Joseph Cheek
2006-05-04 13:48 ` Alan Cox
2006-05-04 14:14   ` Christian Trefzer
2006-05-04 15:28     ` Alan Cox
2006-05-04 17:54       ` Christian Trefzer [this message]
2006-05-04 16:50   ` Wakko Warner
2006-05-04 17:10     ` Alan Cox
2006-05-04 17:27       ` Joshua Hudson
2006-05-04 20:47         ` Wakko Warner
2006-05-05  0:10           ` Joshua Hudson
2006-05-05  0:20             ` Wakko Warner
2006-05-04 20:56   ` kernel keeps empty CDROM(DVD)-drive "busy"; (was Re: cdrom: a dirty CD can freeze your system) Linda Walsh

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=20060504175441.GA2910@hermes.uziel.local \
    --to=ctrefzer@gmx.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=kernel@wildsau.enemy.org \
    --cc=linux-kernel@vger.kernel.org \
    /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