On Fri, 2010-07-02 at 03:28 +0100, Russell Marks wrote: > Ben Hutchings <ben@decadent.org.uk> wrote: > > > On Tue, 2010-06-29 at 03:35 +0100, Russell Marks wrote: > >> > hdparm still works with libata-based drivers, so you should not need to > >> > build a custom kernel. > >> > >> As you might imagine, hdparm was the first thing I tried. It seems not > >> all of hdparm's features work with libata-based drivers, in particular I > >> can't disable/enable DMA with it: > >> > >> rus@cartman:2005:/home/rus>sudo hdparm -d 0 /dev/sda > >> > >> /dev/sda: > >> setting using_dma to 0 (off) > >> HDIO_SET_DMA failed: Inappropriate ioctl for device > >> HDIO_GET_DMA failed: Inappropriate ioctl for device > >> rus@cartman:2006:/home/rus>sudo hdparm -d 0 /dev/hda > >> /dev/hda: No such file or directory > >> rus@cartman:2007:/home/rus> > > > > Sorry, I thought most hdparm features would still work. > > > > You can still disable DMA by setting a module option for libata. Put > > Or by using a kernel command-line option (e.g. libata.dma=0 which I'm > using for now). But with hdparm I could turn it on and off at run-time, > which is useful on one particular machine I use, and which I don't > believe is possible now. > > I think if changes to the kernel package are partly breaking another > package, which I've demonstrated is happening here, that seems like it > should count as a bug in Debian. Maybe hdparm or even sdparm is more to > blame, I don't know, but I think this has to be a regression somewhere > doesn't it? OK, sure, it's a regression. It is unlikely to be fixed, though, as there is very little reason to control this at run-time. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part