Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: rework the code for selecting the best DMA transfer mode
Here's another portion of comments...
Depends on the "ide: fix UDMA/MWDMA/SWDMA masks" patch.
* add ide_hwif_t.filter_udma_mask hook for filtering UDMA mask
Erm, maybe a
Hello.
Alan wrote:
Ugh, I'm not seeing any *actual* support for MW/SW DMA in this driver...
Thats long been broken. Should be correct in the libata driver
Here's a surprise for you. pata_cmd64x copied the SW/MW DMA setup code
from the IDE driver. No way it could be working. You ma
Hello.
Alan wrote:
Ugh, I'm not seeing any *actual* support for MW/SW DMA in this driver...
Thats long been broken. Should be correct in the libata driver
Here's a surprise for you. pata_cmd64x copied the SW/MW DMA setup code
from the IDE driver. No way it could be working. You may
Hello.
Marc St-Jean wrote:
> 2. Fix for Busy Detect on LCR write
> 3. Workaround for interrupt/data concurrency issue
> case UPIO_MEM:
> +#ifdef CONFIG_PMC_MSP
> + /* Save the LCR value so it can be re-written when a
> + * Busy Detect interrupt occurs. */
> +
Hello.
Adrian Bunk wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c: In
function 'vortex_init_one':
/home/bunk/linux/kerne
Hello.
Marc St-Jean wrote:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc4/2.6.20-rc4-mm1/broken-out/8250-uart-backup-timer.patch
This second patch failure description is identical to what we are seeing without
the THRE work-around. This must be the timer patch Alan
Hello.
Marc St-Jean wrote:
>>This I would hope you can hide in the platform specific
>>serial_in/serial_out functions. If you write the UART_LCR save it in
>>serial_out(), if you read IER etc.
> I couldn't find hooks for platform specific serial_in/out functions.
It's because there are
Hello.
Marc St-Jean wrote:
> I could use both iotype and type with a test on each for the appropriate
> bug, what do you recommend?
I think iotype would be enough. You can't pass type for platform
devices anyway, IIRC (the thing I don't quite like).
I just found that out the hard way,
Marc St-Jean wrote:
Here is my second attempt at the serial driver patch for the
PMC-Sierra MSP71xx device.
There are three different fixes:
1. Fix for THRE errata
- I verified the UART_BUG_TXEN fix does not help with this erratum.
- I left our current fix in until I get our platform booting on
Hello, I wrote:
Contains: IRQ-ack fix for ICH chipsets (Albert Lee), ide-floppy
unformatted
media fix (Alan Cox), more fixes for IDE PCI drivers (Sergei Shtylyov),
new driver for Toshiba Cell Reference Board (Kou Ishizaki at toshiba.co.jp>) and a bunch of rather obvious
cleanups/improveme
Hello, I wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel-2.6/l
Convert the spinlocks in the PowerPC interrupt related code into the raw ones,
also convert the PURR and PMC related spinlocks...
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
Index: linux-2.6/arch/powerpc/
Cheers,
Ben.
In my turn, I'd like to have your (or anybody's) comments since I have
doubts about the nee of some conversions below which Mark have originally done
(though I limited myself to only adding couple more that seemed really necessary)
Signed-off-by: Mark A. G
Hello.
Alan wrote:
On Wed, 07 Feb 2007 19:08:14 +0100
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
- ACPI support for IDE (has been in SuSE kernels for months)
(Hannes Reinecke <[EMAIL PROTECTED]>)
I can find no public copy of this or discussion of it, please post a
http://marc.t
Hello.
Marc St-Jean wrote:
Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx device.
There are three different fixes:
1. Fix for DesignWare THRE errata
- Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm"
tree also fixes it. This patch needs to be applied on
Hello.
Marc St-Jean wrote:
> Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx
device.
> There are three different fixes:
> 1. Fix for DesignWare THRE errata
> - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm"
> tree also fixes it. This patch needs to
Hello.
Marc St-Jean wrote:
>> > Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx
>>device.
I think you need to submit your patch to Andrew Morton since it
requires a patch from his tree.
OK, will do.
In fact, since the serial drivers are not maintained anymore,
Hello.
Marc St-Jean wrote:
There are three different fixes:
1. Fix for DesignWare APB THRE errata:
In brief, this is a non-standard 16550 in that the THRE interrupt
will not re-assert itself simply by disabling and re-enabling the
THRI bit in the IER, it is only re-enabled if a character is act
Hello.
Andrew Morton wrote:
+ status = *(volatile u32 *)up->port.private_data;
It distresses me that this patch uses a variable which this patch
doesn't initialise anywhere. It isn't complete.
I assume this gets passed via early_serial_setup(). Marc?
The sub-dri
Hello.
Marc St-Jean wrote:
> diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
> index 3d91bfc..bfaacc5 100644
> --- a/drivers/serial/8250.c
> +++ b/drivers/serial/8250.c
> @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar
> return inb(up->port.iobase + 1);
>
Hello, I wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one':
/home/bunk/linux/kernel-2.6/li
Hello.
Sergei Shtylyov wrote:
3x59x-fix-pci-resource-management.patch causes the following compile
error with CONFIG_PCI=n:
<-- snip -->
...
CC drivers/net/3c59x.o
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/net/3c59x.c:
In function 'vortex_init_one&#
Hello.
Bartlomiej Zolnierkiewicz wrote:
Contains: IRQ-ack fix for ICH chipsets (Albert Lee), ide-floppy unformatted
media fix (Alan Cox), more fixes for IDE PCI drivers (Sergei Shtylyov),
new driver for Toshiba Cell Reference Board (Kou Ishizaki ) and a bunch of rather obvious cleanups
Hello.
Sergei Shtylyov wrote:
Contains: IRQ-ack fix for ICH chipsets (Albert Lee), ide-floppy
unformatted
media fix (Alan Cox), more fixes for IDE PCI drivers (Sergei Shtylyov),
new driver for Toshiba Cell Reference Board (Kou Ishizaki at toshiba.co.jp>) and a bunch of rather obvious clean
Hello.
Sergei Shtylyov wrote:
Not a suprise to be honest. I fixed some of the ALi stuff when I did it
and I think that was pushed back into drivers/ide. The CMD64x hasn't had
much love really.
Another buglet found by random glancing at this driver:
/**
* cmd648_dma
Hello.
Bartlomiej Zolnierkiewicz wrote:
The other advantage of doing cleanups is that code becomes cleaner/simpler
which matters a lot for this codebase, i.e. ide-dma-off-void.patch exposed
(yet to be fixed) bug in set_using_dma() (->ide_dma_off_quietly always returns
0 which is passed by ->ide
Hello.
Marc St-Jean wrote:
> Here is my second attempt at the serial driver patch for the
> PMC-Sierra MSP71xx device.
> There are three different fixes:
> 1. Fix for THRE errata
> - I verified the UART_BUG_TXEN fix does not help with this erratum.
> - I left our current fix in until I get o
Hello.
Alan wrote:
Ugh, I'm not seeing any *actual* support for MW/SW DMA in this driver...
Thats long been broken. Should be correct in the libata driver
I've looked thru the specs and it seemed to me that ULi hardware is much
broken PIO wise: their max active time is 8 cycles even
Hello.
Ingo Molnar wrote:
as usual, bugreports, fixes and suggestions are welcome,
Be aware that even with the newest -rt patch, the PowerPC TOD
vsyscalls are still broken, i.e. glibc may return imprecise/incorrect
results for the related calls -- despite arch/powerpc/kernel/time.c
has b
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
could you resend them to me please?
Seeing that GENERIC_TIME has been thrown out from the -rt patch,
[...]
hm, i did that accidentally during a rebase. That was c
Hello.
Bartlomiej Zolnierkiewicz wrote:
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -695,9 +695,10 @@ static void __devinit init_hwif_cmd64x(i
hwif->swdma_mask = 0x07;
ff-by: Sergei Shtylyov <[EMAIL PROTECTED]>
What was the destiny of that patch? I haven't seen it accepted, haven't
seen any comments... while this is not a mere warning fix. What am I expected
to do to get it accepted -- recast it against 2.6.19-rt1?
kernel/l
Hello.
Ingo Molnar wrote:
What was the destiny of that patch? I haven't seen it accepted,
haven't seen any comments... while this is not a mere warning fix.
What am I expected to do to get it accepted -- recast it against
2.6.19-rt1?
i'd suggest to redo it - but please keep it simple and
Hello.
Ingo Molnar wrote:
i'd suggest to redo it - but please keep it simple and clean. Those
dozens of casts to u64 are quite ugly.
Alas, there's *nothing* I can do about it with 32-bit cycles_t.
[...]
there's *always* a way to do such things more cleanly - such as the
patch below. Cou
Hello.
Ingo Molnar wrote:
/* check for buggy clocks, handling wrap for 32-bit clocks */
- if (TYPE_EQUAL(cycles_t, unsigned long)) {
+ if (TYPE_EQUAL(cycle_t, unsigned long)) {
if (time_after((unsigned long)T1, (unsigned long)T2))
prin
Hello.
Sergei Shtylyov wrote:
Why is cycles_t 32-bits on some
of the arches to begin with?
I guess this was done for speed reasons.
The whole 64-bit timebase can't be rad atomically on PPC32. ARM probably
has stricter limitations...
Ingo
WBR, Sergei
-
To unsubs
The particularly nasty
"limitation 5" (as they call the errata) caused me to abuse the IDE core in a
possibly most interesting way so far. However, this is still better than the
#ifdef mess in drivers/ide/ide-io.c that the original version included (well,
it had much more mess)...
Signed
Hello.
On Wednesday 13 December 2006 01:48, Sergei Shtylyov wrote:
> Behold! This is the driver for the Toshiba TC86C001 GOKU-S IDE controller,
> completely reworked from the original brain-damaged Toshiba's 2.4 version.
Shoot, the patch is actually against the most recent Linu
much more mess)...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
drivers/ide/Kconfig|5
drivers/ide/pci/Makefile |1
drivers/ide/pci/tc86c001.c | 304 +
drivers/pci/quirks.c | 18 ++
include/linux/pci_ids.h|1
Hello.
Alan wrote:
+ * We work around this by initiating dummy, zero-length DMA transfer on
+ * a DMA timeout expiration. I found no better way to do this with the current
Novel workaround and probably better than resetting the chip as the
winbong does.
I didn't try resetting however th
The particularly nasty
"limitation 5" (as they call the errata) caused me to abuse the IDE core in a
possibly most interesting way so far. However, this is still better than the
#ifdef mess in drivers/ide/ide-io.c that the original version included (well,
it had much more mess)...
Signed
Hello everybody.
Ingo Molnar wrote:
i have released the 2.6.19-rt6 tree, which can be downloaded from the
usual place:
http://redhat.com/~mingo/realtime-preempt/
[...]
as usual, bugreports, fixes and suggestions are welcome,
Be aware that even with the newest -rt patch, the Powe
Hello.
Adrian Bunk wrote:
+toshiba-tc86c001-ide-driver-take-2.patch
This patch makes the needlessly global init_hwif_tc86c001() static.
Duh, I hoped tha this driver may get into 2.6.20-rc1 and finally
overlooked this. Sigh, uou won't believe how much time this driver rewrite
spent in
Hello.
Adrian Bunk wrote:
This patch makes the needlessly global init_hwif_tc86c001() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
If this patch hasn't been accepted by Andrew yet, could you add another
fixlet: init_chipset_tc86c001() should've been __devinit. If not or it's
As fasteoi type chips never had to define their ack() method before the
recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler
in thread resulted in the kernel crash. So, define their ack() methods to be
the same as their eoi() ones...
Signed-off-by: Sergei Shtylyov &l
ones...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
Since there was no feedback on three solutions I suggested, I'm going the way
of least resistance and making the fasteoi type chips behave the way that
handle_fasteoi_irq() is expecting from them...
Wait wait wait .
Hello.
Benjamin Herrenschmidt wrote:
* Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
Wait wait wait Can somebody (Ingo ?) explain me why the fasteoi
handler is being changed and what is the rationale for adding an ack
that was not necessary before ?
dont worry, it's -rt only stu
Hello.
Ingo Molnar wrote:
What do you need an ack() for on fasteoi ? On all fasteoi controllers
I have, ack is implicit by obtaining the vector number and all there
is is an eoi...
it's a compatibility hack only. Threaded handlers are a different type
of flow, but often the fasteoi handler
Hello.
Benjamin Herrenschmidt wrote:
I must not that this whole ack() vs eoi() stuff is misleading. For example,
in 8259 driver, mask_ack() method actually sends EOI to PIC, not ACK's an IRQ
-- the actual ACK is implicit on x86 and is used to read the interrupt vector
form 8259 on PPC. So,
Hello.
Benjamin Herrenschmidt wrote:
The fasteoi flow seem to only had been used for x86 IOAPIC in the RT patch
only *before* PPC took to using them in the mainline...
I don't think so, I asked for the fasteoi to be created while porting
ppc to genirq :-)
Oh, I was unaware of such det
Hello.
Sergei Shtylyov wrote:
On MPIC or XICS, this is implicit by reading the vector. On some more
dumb controllers, this has to be done explicitely.
This is not implicit -- CPU has to read INTACK reg. on OpenPIC. Really
Sorry, it's the same for x86 version of OpenPIC accordi
Hello.
Benjamin Herrenschmidt wrote:
EOI is a more "high level" thing that some "intelligent" PICs that
automatically raise the priority do to restore the priority to what it
was before the interrupt occured.
Thank you, I know. Even 8259 has the notion of priority and EOI works the
same w
Hello.
[EMAIL PROTECTED] wrote:
I think reading the IDE status register clears the interrupt in the IDE
device, which might be causing the drive to think it's OK to generate
another interrupt.
This is not how IDE drives are supposed to act -- they won't proceed any
further until "interrupt
Hello.
Alan Cox wrote:
I can prepare a patch, but only with a lot of guidance. I can test
& debug, I'm highly motivated just right now ...
If you've got a nice repeatable problem please try using the libata
driver. That handles the error paths differently and doesn't try a FIFO
drain which m
Alan Cox wrote:
I can prepare a patch, but only with a lot of guidance. I can test
& debug, I'm highly motivated just right now ...
If you've got a nice repeatable problem please try using the libata
driver. That handles the error paths differently and doesn't try a FIFO
drain which might ma
Mark Lord wrote:
I can prepare a patch, but only with a lot of guidance. I can test
& debug, I'm highly motivated just right now ...
If you've got a nice repeatable problem please try using the libata
driver. That handles the error paths differently and doesn't try a
FIFO
drain which might
Hello.
Linas Vepstas wrote:
[EMAIL PROTECTED] wrote:
I think reading the IDE status register clears the interrupt in the IDE
device, which might be causing the drive to think it's OK to generate
another interrupt.
This is not how IDE drives are supposed to act -- they won't proceed any
Alan Cox wrote:
Indeed... but the thing is we don't know what's asserted in this case
-- remember, it's reading the status register that locks everything up...
Exactly. And IORDY shouldn't really apply there,
unless some nitwit standards person wrote it into a spec..
Could it be we need
Bartlomiej Zolnierkiewicz wrote:
There are two distinct issues.
-- libata locks up in partition table read on an hpt366+old maxtor disk
that has ben working fine for many years with old ide driver. (It
still works fine when I boot to the alternate ide-based kernel).
-- ide driver locks up
Hello.
Tony Breeds wrote:
plain text document attachment
(clocksource-add-settimeofday-hook.patch)
From: Tony Breeds <[EMAIL PROTECTED] >
I'm working on a clocksource implementation for all powerpc platforms.
some of these platforms needs to do a little work as part of the
settimeofday() sys
Daniel Walker wrote:
+static void clocksource_settimeofday(struct clocksource *cs,
+ struct timespec *ts)
+{
+ u64 new_xsec;
+
+#ifdef CONFIG_PPC_ISERIES
+ if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
+ iSeries
Hello.
Thomas Gleixner wrote:
+void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
+{
+ timer_recalc_offset(tb_last_jiffy);
+ timer_check_rtc();
+}
Hmm .. This doesn't look like it's taking into account that the time has
changed ..
Why? By the time it
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: use PIO/MMIO operations directly where possible
This results in smaller/faster/simpler code and allows future optimizations.
Also remove no longer needed ide[_mm]_{inl,outl}() and ide_hwif_t.{INL,OUTL}.
Signed-off-by: Bartlomiej Zolnierk
Hello.
Alan Cox wrote:
Google seems to show that there is no publically available
firmware updates for Maxtor disks.
There are for some but only if you irritate the tech support people.
hours at high cpu usage There were maybe a a dozen DriveReady
SeekComplete Timeout errors clustered
Tony Breeds wrote:
Thanks for taking the time to look over my patch.
I guess it's been based on the prior work by John Stultz (and me too :-)?
At some level I guess so. John did send me a patch a while ago.
If you mean the init. part, this has been already done by me -- I've
Linas Vepstas wrote:
I've got a hard lockup in the ide subsystem, probably
due to some irq spew or something like that.
I've just bought a brand new Maxtor 320GB disk driver
for the insane price of $70 US to replace another
failing drive. It works well under light load;
I was able to copy ab
Bartlomiej Zolnierkiewicz wrote:
On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
It can be changed via /proc/ide/hd?/settings.
Why do we need to change IDE DMA timeout dynamically?
I've used it to test error re
Albert Lee wrote:
Alan Cox wrote:
ata_scsi_pass_thru() is not executed at ioctl submission time (block
queue submission time), but rather immediately before it is issued to
the drive. At that point you know the bus is idle, all other commands
have finished executing, and dev->multi_count is
Hello.
Bartlomiej Zolnierkiewicz wrote:
This patch allows users to override both host and device side cable detection
with "ideX=ata66" kernel parameter. Thanks to this it should be now possible
to use UDMA > 2 modes on systems (laptops mainly) which use short 40-pin cable
instead of 80-pin on
Hello.
Bartlomiej Zolnierkiewicz wrote:
This patch allows users to override both host and device side cable detection
with "ideX=ata66" kernel parameter. Thanks to this it should be now possible
to use UDMA > 2 modes on systems (laptops mainly) which use short 40-pin cable
instead of 80-pin on
Hello.
Vitaly Bordug wrote:
This updates relevant platform code
(freescale mpc8349itx target) to make the CompactFlash
work in TrueIDE mode.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
It would have been good if you tried to actual
Arnd Bergmann wrote:
This adds support for MMIO IDE device like CompactFlash
in TrueIDE mode.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
Hmm, are we still adding new IDE drivers? Do you also have a
Yes, why not?
driver for the
Hello.
Vitaly Bordug wrote:
This adds support for MMIO IDE device like CompactFlash
in TrueIDE mode.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
[...]
diff --git a/drivers/ide/legacy/mmio-ide.c b/drivers/ide/legacy/mmio-ide.c
new fi
Hello.
Bartlomiej Zolnierkiewicz wrote:
On Feb 20, 2007, at 5:44 PM, Bartlomiej Zolnierkiewicz wrote:
On Wednesday 21 February 2007 02:19, Suleiman Souhlal wrote:
It can be changed via /proc/ide/hd?/settings.
Why do we need to change IDE DMA timeout dynamically?
I've used it to test
Hello.
Jeff Garzik wrote:
3x59x-fix-pci-resource-management.patch
Now that the fix for CONFIG_PCI=n has been merged, what's left is to test
this on EISA (at least Andrew wanted it :-).
netdev patches which are stuck in limbo land.
? I don't think I've seen these.
You should h
Hello.
Andrew Morton wrote:
3x59x-fix-pci-resource-management.patch: you wrote it ;) I have a comment
No, I did, almost a year ago already. :-)
here:
- I don't remember the story with cardbus either. Presumably once upon a
time the cardbus layer was claiming IO regions on behalf of
Songmao Tian wrote:
Hi,
I am trying to use a mips cpu the cs5536. I have some problem with
the 8259 of cs5536. The databook said,
Which databook?
"Control Logic
The INT output goes directly to the CPU interrupt input.
When an INT signal is activated, the CPU responds with an
Interr
Hello, I wrote:
it's a problem that my northbridge didn't implement that! Fortunately
we use a fpga as a northbridge.
Wait, CS5536 is a nortbridge itself!
Apparently, it's only a south bridge. I must've mixed it with Geode itself.
WBR, Sergei
-
To unsubscribe from this list: send the
Hello.
Maciej W. Rozycki wrote:
"Control Logic
The INT output goes directly to the CPU interrupt input.
When an INT signal is activated, the CPU responds with an
Interrupt Acknowledge access that is translated to two
pulses on the INTA input of the PIC. At the first INTA pulse,
the highest prio
Hello.
Vitaly Bordug wrote:
+
+#ifdef CONFIG_MPC834x_ITX
Erm, isn't this stuff misplaced? Is this really SoC device? I
remember seeng this in the arch/ppc/ platform code before (in the
internal tree)...
The point is to declare methods bsp, as mmio access may effectively vary
(having
Hello, I wrote:
Revert the change to the "fasteoi" type chips as after handle_fasteoi_irq() had
been fixed, they've become meaningless (and even dangerous -- as was the case
with Celleb that has been fixed earlier)...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
Hello.
Mark Lord wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs,
and if DMA is
not complete or interrupt pending, it may wait 10 more secs...
I really don't remember... :)
Maybe Mark or Alan could help with figuring this out.
They also have probably forg
Hello.
Andrew Morton wrote:
I saw a similar report yesterday with '2.6.21.1 - 97% wait time on IDE
operations' subject.
After upgrading from 2.6.20.7 kernel to 2.6.21.1 my system started to
reset infrequenly the IDE bus. In the syslog DMA timeout, resetting IDE
bus messages appeared. I've c
Hello.
Geller Sandor wrote:
I saw a similar report yesterday with '2.6.21.1 - 97% wait time on
IDE operations' subject.
After upgrading from 2.6.20.7 kernel to 2.6.21.1 my system started
to reset infrequenly the IDE bus. In the syslog DMA timeout,
resetting IDE bus messages appeared. I've c
Hello.
Thomas Gleixner wrote:
Now that the -rt patch has been first release in the broken-out version,
let me tell you that the following 3 patches in the series can be just
annihilated:
preempt-irqs-ppc-ack-irq-fixups.patch
preempt-irqs-ppc-fix-b5.patch
preempt-irqs-ppc-fix-more-fasteoi
Mark Lord wrote:
I've lost the original question from this thread, but the idea of the
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
longish
timeouts was that drive *may* be spun down ("standby"), and
Mark Lord wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20
secs, and if DMA is not complete or interrupt pending, it may wait
10 more secs...
..
I've lost the original question from this thread, but the idea of the
The original question concerned specifically th
Mark Lord wrote:
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds)...
When a drive is in standby, we don't send it anything special to wake
up.
So even DMA commands have to have a long enough timeout to allow
Hello.
Rogier Wolff wrote:
Ah, that makes sense -- during PIO interrupts happen a lot more often.
20 secs still seem to be too much.
I don't think so, even for modern drives.
Figure 8-10 seconds max for spin-up,
plus 6-9 seconds to do a sector re-assignment
or retries on a bad block (a meas
Remove PowerPC vsyscalls that were broken by the generic TOD patch.
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
Since there's still no working PowerPC TOD vsyscalls fix, and they continue to
be broken in the RT patch, I've respun this patch again...
arch/power
Revert the change to the "fasteoi" type chips as after handle_fasteoi_irq() had
been fixed, they've become meaningless (and even dangerous -- as was the case
with Celleb that has been fixed earlier)...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
The patch in
-- this option is not compatible with the PPC64
deterministic time accounting.
Thanks to Daniel Walker and Thomas Gleixner for the suggestions they made...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
This patch has been reworked against the 2.6.21 clockevents framework.
It ha
Enable HRT and dynamic ticks support for PowerPC.
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
This patch has been reworked against the 2.6.21 clockevents framework.
It has only been tested on the Book E 32-bit CPU this time, so re-testing on
"classic" PowerPC CPUs
Hello.
Kumar Gala wrote:
Index: linux-2.6/arch/powerpc/kernel/time.c
===
--- linux-2.6.orig/arch/powerpc/kernel/time.c
+++ linux-2.6/arch/powerpc/kernel/time.c
[...]
@@ -128,6 +129,83 @@ unsigned long ppc_tb_freq;
static u64 tb_
Here's the read_persistent_clock() implementation for PowerPC.
I'm deliberately renaming get_boot_time() despite it's not static as it
doesn't get called from anywhere else.
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
Have almost forgotten about this on
Hello.
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any utility
in having support for more than one clock source?
Of course, you may register as many as you like.
- k
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Hello.
Kumar Gala wrote:
Kumar Gala wrote:
I haven't looked at all the new clock/timer code, is there any
utility in having support for more than one clock source?
Of course, you may register as many as you like.
Sure, but is there any utility in registering more than the decremen
Segher Boessenkool wrote:
+ * We must write a positive value to the decrementer to clear
+ * the interrupt on the IBM 970 CPU series. In periodic mode,
+ * this happens when the decrementer gets reloaded later, but
+ * in one-shot mode, we have to do it here since an event handle
Segher Boessenkool wrote:
+ * We must write a positive value to the decrementer to clear
+ * the interrupt on the IBM 970 CPU series. In periodic mode,
+ * this happens when the decrementer gets reloaded later, but
+ * in one-shot mode, we have to do it here since an event handle
Geller Sandor wrote:
Hello.
The log of a typical IDE reset is available here:
http://petra.hos.u-szeged.hu/~wildy/syslog.gz
This was the worst case: the IDE bus was resetted during the system
boot.
Could you try setting HPT374_ALLOW_ATA133_6 to 0 in
drivers/ide/pci/hpt366.c and rebuil
501 - 600 of 2411 matches
Mail list logo
