patch 1/4: Reorder HSM_ST_FIRST
patch 2/4: Clear tf before doing request sense
patch 3/4: Limit max sector to 240 for TORiSAN DVD drives
patch 4/4: Limit ATAPI DMA to R/W commands only for TORiSAN DVD drives
(patch 2/4 revised per Tejun's advice.)
-
To unsubscribe from this list: send the line "u
patch 1/4:
Reorder HSM_ST_FIRST, such that the task state transition is easier decoded
with human eyes.
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
Patch against libata-dev tree, for your review, thanks.
diff -Nrup 00_libata-dev.ori/include/linux/libata.h
01_hsm_st/include/linux/libata.
patch 2/4:
Clear tf before doing request sense.
This fixes the AOpen 56X/AKH timeout problem.
(http://bugzilla.kernel.org/show_bug.cgi?id=8244)
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
Revised per Tejun's advice to use result_tf instead.
Patch against libata-dev tree, for your review,
patch 3/4:
The TORiSAN drive locks up when max sector == 256.
Limit max sector to 240 for TORiSAN DRD-N216 drives.
(http://bugzilla.kernel.org/show_bug.cgi?id=6710)
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
Patch against libata-dev tree, for your review, thanks.
diff -Nrup 02_aopen_
patch 4/4:
Limit ATAPI DMA to R/W commands only for TORiSAN DRD-N216 DVD-ROM drives
(http://bugzilla.kernel.org/show_bug.cgi?id=6710)
Signed-off-by: Albert Lee <[EMAIL PROTECTED]>
---
I guess maybe other commands like READ_DVD_STRUCTURE and READ_CD also
work under ATAPI DMA, but not confirmed
Albert Lee wrote:
patch 1/4: Reorder HSM_ST_FIRST
patch 2/4: Clear tf before doing request sense
patch 3/4: Limit max sector to 240 for TORiSAN DVD drives
patch 4/4: Limit ATAPI DMA to R/W commands only for TORiSAN DVD drives
(patch 2/4 revised per Tejun's advice.)
All four look good to me.
On Saturday 31 March 2007, Tejun Heo wrote:
> Albert Lee wrote:
> > patch 1/4: Reorder HSM_ST_FIRST
> > patch 2/4: Clear tf before doing request sense
> > patch 3/4: Limit max sector to 240 for TORiSAN DVD drives
> > patch 4/4: Limit ATAPI DMA to R/W commands only for TORiSAN DVD drives
> >
> > (
Mark Rustad wrote:
On Mar 27, 2007, at 1:38 PM, Jeff Garzik wrote:
Mark Rustad wrote:
reorder any queued operations. Of course if you really care about
your data, you don't really want to turn write cache on.
That's a gross exaggeration. FLUSH CACHE and FUA both ensure data
integrity as
On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> >
> > Subject: kernels fail to boot with drives on ATIIXP controller
> > (ACPI/IRQ related)
> > References : https://bugzilla.redhat.com/bugzilla/sho
I have a Sil3124 controller and four drives, and I'm trying to build a
large JBOD file server (with three or four of those controller+drive sets).
One of the things I would need to be able to do in order to practically do
that is to have reasonable staggered spin-up; that is, I need to not have a
On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> Subject: Add suspend/resume for HPET
> This adds support of suspend/resume on i386 for HPET
> Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
>
> +static struct sysdev_class hpet_class = {
> + set_kset_name("hpet"),
> + .suspend
On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
caused by time keeping / tick management resume happening before the
HPET resume.
me>Confirmed that suspend/resume disk/ram works on X60s with
me>CONFIG_HPET_TIMER=y an
On Sun, 2007-04-01 at 00:01 +0800, Jeff Chua wrote:
> On 3/31/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > Jeff still seems to have problems with CONFIG_NO_HZ=n and it might be
> > caused by time keeping / tick management resume happening before the
> > HPET resume.
>
>
> me>Confirmed th
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
>
> While I agree in principle with the patch, I'm a bit uncomfortable. The
> sys device suspend / resume ordering is not guaranteed and relies on the
> registering order.
Well, this is why we probably should try to get away from the "system
device"
On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > sys device suspend / resume ordering is not guaranteed and relies on the
> > registering order.
>
> Well, t
On Sat, Mar 31, 2007 at 06:33:20PM +0200, Thomas Gleixner wrote:
> On Sat, 2007-03-31 at 09:09 -0700, Linus Torvalds wrote:
> >
> > On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> > >
> > > While I agree in principle with the patch, I'm a bit uncomfortable. The
> > > sys device suspend / resume ord
On Sat, Mar 31, 2007 at 05:01:23PM +0200, Adrian Bunk wrote:
> On Fri, Mar 30, 2007 at 06:23:10PM -0600, Michal Jaegermann wrote:
> > On Fri, Mar 30, 2007 at 11:32:09PM +0200, Adrian Bunk wrote:
> > >
> > > Subject: kernels fail to boot with drives on ATIIXP controller
> > > (ACPI
Tejun Heo wrote:
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
+++ linux/drivers/
On Saturday 31 March 2007 18:51:11 Thomas Gleixner wrote:
> On Thu, 2007-03-29 at 15:46 +0200, Maxim Levitsky wrote:
> > Subject: Add suspend/resume for HPET
> > This adds support of suspend/resume on i386 for HPET
> > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
> >
> > +static struct sysdev_
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
>
> Right, but clock - sources/events need to be extremly late suspended and
> early resumed. How can we ensure this ?
Make them be at the top of the device tree by adding them early. That's
the whole point of the device tree after all - we have an o
Mark Lord wrote:
Tejun Heo wrote:
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
[...]
> So the only thing that needs to be done is to make sure that we add
> t
On Sat, Mar 31, 2007 at 09:53:43AM -0700, Linus Torvalds wrote:
> Make them be at the top of the device tree by adding them early. That's
> the whole point of the device tree after all - we have an ordering that is
> enforced by its topology, and that we sort by when things were added.
>
> Right
On Sat, 31 Mar 2007, Maxim Levitsky wrote:
>
> So maybe I was right afrer all,
> Maybe it is better to add a suspend/resume hook to each clock source and call
> it from timekeeping_resume() ?
Umm.. WHy not make the device tree look like this:
-- "clocksource" -- +-- HPET
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Umm.. WHy not make the device tree look like this:
>
> -- "clocksource" -- +-- HPET
> |
> +-- TSC
> |
> +-- i8259
>
On Saturday 31 March 2007 9:53 am, Linus Torvalds wrote:
>
> On Sat, 31 Mar 2007, Thomas Gleixner wrote:
> >
> > Right, but clock - sources/events need to be extremly late suspended and
> > early resumed. How can we ensure this ?
>
> Make them be at the top of the device tree by adding them earl
On Sat, 2007-03-31 at 19:17 +0200, Ingo Molnar wrote:
> yeah. There's some practical problems that need to be sorted out: much
> of the current GTOD code is irq-driven (and all GTOD locks are
> irq-safe), while the sysfs code needs to run in process-context level.
>
> Clocksources 'arrive' and
( please remove obsolute [EMAIL PROTECTED] from further messages!! )
On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
>
> i dont think there's any particular problem here because suspend/resume
> wont be done during bootup - but we might need a way to move a device to
> earlier spots in
This email lists some known regressions in Linus' tree compared to 2.6.20
with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any ot
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Hm, but as long as dk0 is registered, it can be looked up and someone
> > could get a reference on it.
>
> Yeah, exactly. That's why any getting any kobject reference backed by a
> module must be accompanied by try_modu
Cornelia Huck wrote:
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
Hm, but as long as dk0 is registered, it can be looked up and someone
could get a reference on it.
Yeah, exactly. That's why any getting any kobject reference backed by a
module must be accompanied b
On Saturday 31 March 2007 11:18 am, David Brownell wrote:
> ( please remove obsolute [EMAIL PROTECTED] from further messages!! )
>
> On Saturday 31 March 2007 10:02 am, Ingo Molnar wrote:
> >
> > i dont think there's any particular problem here because suspend/resume
> > wont be done during boo
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc5-mm2:
>...
> +testing-patch-for-ali-pata-fixes-hopefully-for-the-problems-with-atapi-dma.patch
>
> pata experiment
>...
This patch makes the needlesly global ali_tf_load() static.
Signed-off-by: Adria
Hello,
I discovered a reproducible way of causing silent file corruption.
Unfortunately, this method happens to me my backup procedure :(.
Background: I have five hard drives. sda and sdb are on a SiI 3112
card. sdc and sdd use onboard sata_via. hda uses onboard VIA VT8237
IDE. All filesystems ar
> On Sat, 31 Mar 2007 18:27:36 -0700 Aaron Lehmann <[EMAIL PROTECTED]> wrote:
> I have spent a lot of time trying to find a simpler test case. So far,
> as far as I can tell, there are three conditions that must be
> satisfied for corruption to occur:
>
> 1. Heavy Ethernet load (nc remotehost < /d
Aaron Lehmann wrote:
> I discovered a reproducible way of causing silent file corruption.
...
> 1. Heavy Ethernet load (nc remotehost < /dev/zero)
> 2. Heavy disk write load on any non-sata_sil drive (cat /dev/zero > /path)
> 3. Heavy disk read load on any other drive (tar c /path | cat > /dev/null
On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote:
for those will all get grouped together ... suspended "very late" and
resumed "very early", regardless of when they get registered. Pretty
much the driver model parts of what Linus was suggesting; clockevent
bits would still be needed.
I tes
On Sat, Mar 31, 2007 at 07:52:36PM -0700, Andrew Morton wrote:
> Are you able to provide us with some before-and-after data so we
> can see this corruption.
>
> See, if it's dropped-bits or shifted-data or eight-byte-aligned
> kernel addresses or whatever, that helps us generate theories..
Sure.
On Saturday 31 March 2007 8:13 pm, Jeff Chua wrote:
> On 4/1/07, David Brownell <[EMAIL PROTECTED]> wrote:
> > for those will all get grouped together ... suspended "very late" and
> > resumed "very early", regardless of when they get registered. Pretty
> > much the driver model parts of what Linu
On Sat, Mar 31, 2007 at 08:03:16PM -0700, Jim Paris wrote:
> Since it shows up under heavy load that includes unrelated devices, I
> think ruling out hardware problems is important. Some suggestions:
I've been able to narrow it down to the Realtek Ethernet card. I can't
reproduce the problem usin
40 matches
Mail list logo
