RE: Lost interrupt with cmd 64x
On Friday 23 November 2007, Sergei Shtylyov wrote: Hello. Bartlomiej Zolnierkiewicz wrote: This problem should have been already fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6183289cd4356b790c5eaa619020fb887ec0fa44 which was merged into 2.6.24-rc3. Put your attenction at the version against which this was reported -- it's eralier than when the regression was introduced. Indeed, you are correct! However it still would be worth to give 2.6.24-rc3 a try. Hello, sorry for getting back so late on this. I did try 24-rc3 with no luck. For info, I only have one disk connected to the card. Anything else I can try? Tobias _ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007- 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: [PATCH 2/2] ide-scsi: use print_hex_dump from linux/kernel.h
On Nov 26, 2007 3:41 PM, Joe Perches [EMAIL PROTECTED] wrote:
On Mon, 2007-11-26 at 15:16 +0800, Denis Cheng wrote:
diff --git a/drivers/scsi/ide-scsi.c b/drivers/scsi/ide-scsi.c
index 8d0244c..8f3fc1d 100644
--- a/drivers/scsi/ide-scsi.c
+++ b/drivers/scsi/ide-scsi.c
@@ -282,7 +272,7 @@ static int idescsi_check_condition(ide_drive_t *drive,
struct request *failed_co
pc-scsi_cmd = ((idescsi_pc_t *) failed_command-special)-scsi_cmd;
if (test_bit(IDESCSI_LOG_CMD, scsi-log)) {
printk (ide-scsi: %s: queue cmd = , drive-name);
- hexdump(pc-c, 6);
+ print_hex_dump(KERN_DEBUG, , DUMP_PREFIX_OFFSET, 16, 1,
pc-c, 6, 1);
}
rq-rq_disk = scsi-disk;
return ide_do_drive_cmd(drive, rq, ide_preempt);
Hi Denis.
These aren't really equivalent. You need to look at the
line above to determine if a KERN_ prefix needs to be
used at all.
You should probably use print_hex_dump_bytes here.
I know this is different from the original hexdump in ide-scsi.c, I
just want to tell someone that there's a good implementation of
hexdump in kernel.h, and I think the default KERN_DEBUG and
print_hex_dump is more informative and has better output. However,
anyone want more precise control on debug message could make her/his
improvements with print_hex_dump.
cheers, Joe
--
Denis Cheng
-
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
[PATCH] [libata] Return proper ATA INT status in pata_bf54x driver.
INT status can be OR.
Signed-off-by: Sonic Zhang [EMAIL PROTECTED]
---
drivers/ata/pata_bf54x.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c
index b5e3842..81db405 100644
--- a/drivers/ata/pata_bf54x.c
+++ b/drivers/ata/pata_bf54x.c
@@ -1145,13 +1145,13 @@ static unsigned char bfin_bmdma_status(s
unsigned short int_status = ATAPI_GET_INT_STATUS(base);
if (ATAPI_GET_STATUS(base) (MULTI_XFER_ON|ULTRA_XFER_ON)) {
- host_stat = ATA_DMA_ACTIVE;
+ host_stat |= ATA_DMA_ACTIVE;
}
if (int_status (MULTI_DONE_INT|UDMAIN_DONE_INT|UDMAOUT_DONE_INT)) {
- host_stat = ATA_DMA_INTR;
+ host_stat |= ATA_DMA_INTR;
}
if (int_status (MULTI_TERM_INT|UDMAIN_TERM_INT|UDMAOUT_TERM_INT)) {
- host_stat = ATA_DMA_ERR;
+ host_stat |= ATA_DMA_ERR;
}
return host_stat;
--
1.4.3.4
-
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
[PATCH RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
Make pdc_atapi_pkt() use values from qc-tf instead of creating its
own. This is to ease future ATAPI handling changes.
DONT APPLY YET
---
Mikael, would this work? Values other than lbam and lbah remain the
same. Does sata_promise have strict requirements for lbam and lbah?
Thanks.
drivers/ata/sata_promise.c | 34 +-
1 file changed, 13 insertions(+), 21 deletions(-)
Index: work/drivers/ata/sata_promise.c
===
--- work.orig/drivers/ata/sata_promise.c
+++ work/drivers/ata/sata_promise.c
@@ -450,7 +450,7 @@ static void pdc_atapi_pkt(struct ata_que
struct pdc_port_priv *pp = ap-private_data;
u8 *buf = pp-pkt;
u32 *buf32 = (u32 *) buf;
- unsigned int dev_sel, feature, nbytes;
+ unsigned int dev_sel, feature;
/* set control bits (byte 0), zero delay seq id (byte 3),
* and seq id (byte 2)
@@ -473,45 +473,37 @@ static void pdc_atapi_pkt(struct ata_que
buf32[2] = 0; /* no next-packet */
/* select drive */
- if (sata_scr_valid(ap-link)) {
+ if (sata_scr_valid(ap-link))
dev_sel = PDC_DEVICE_SATA;
- } else {
- dev_sel = ATA_DEVICE_OBS;
- if (qc-dev-devno != 0)
- dev_sel |= ATA_DEV1;
- }
+ else
+ dev_sel = qc-tf.device;
+
buf[12] = (1 5) | ATA_REG_DEVICE;
buf[13] = dev_sel;
buf[14] = (1 5) | ATA_REG_DEVICE | PDC_PKT_CLEAR_BSY;
buf[15] = dev_sel; /* once more, waiting for BSY to clear */
buf[16] = (1 5) | ATA_REG_NSECT;
- buf[17] = 0x00;
+ buf[17] = qc-tf.nsect;
buf[18] = (1 5) | ATA_REG_LBAL;
- buf[19] = 0x00;
+ buf[19] = qc-tf.lbal;
/* set feature and byte counter registers */
- if (qc-tf.protocol != ATA_PROT_ATAPI_DMA) {
+ if (qc-tf.protocol != ATA_PROT_ATAPI_DMA)
feature = PDC_FEATURE_ATAPI_PIO;
- /* set byte counter register to real transfer byte count */
- nbytes = qc-nbytes;
- if (nbytes 0x)
- nbytes = 0x;
- } else {
+ else
feature = PDC_FEATURE_ATAPI_DMA;
- /* set byte counter register to 0 */
- nbytes = 0;
- }
+
buf[20] = (1 5) | ATA_REG_FEATURE;
buf[21] = feature;
buf[22] = (1 5) | ATA_REG_BYTEL;
- buf[23] = nbytes 0xFF;
+ buf[23] = qc-tf.lbam;
buf[24] = (1 5) | ATA_REG_BYTEH;
- buf[25] = (nbytes 8) 0xFF;
+ buf[25] = qc-tf.lbah;
/* send ATAPI packet command 0xA0 */
buf[26] = (1 5) | ATA_REG_CMD;
- buf[27] = ATA_CMD_PACKET;
+ buf[27] = qc-tf.command;
/* select drive and check DRQ */
buf[28] = (1 5) | ATA_REG_DEVICE | PDC_PKT_WAIT_DRDY;
-
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
[PATCH #upstream-fixes] libata: bump transfer chunk size if it's odd
None of the drives I have follows what the standard says about transfer chunk size. Of the four SATA and six PATA ATAPI devices tested, four ignore transfer chunk size completely and the ones which honor it don't behave according to the spec when it's odd. According to the spec, transfer chunk size can be odd if the amount of data to transfer equals or is smaller than the chunk size and the device can indicate the same odd number and transfer the whole thing at one go with a pad byte appended. However, in reality, none of the drives I have does that. They all indicate and transfer even number of bytes one byte shorter than the chunk size first; then indicate and transfer two bytes, which is clearly out of spec. In addition to unnecessary second PIO data phase, this also creates a weird problem when combined with SATA controllers which perform PIO via DMA. Some of these controllers use actualy number of bytes received to update DMA pointer so chunks which are sized 4n + 2 makes DMA pointer off by two bytes. This causes data corruption and buffer overruns. This patch rounds nbytes up to the nearest even number such that ATAPI devices don't split data transfer for the last odd byte. This shouldn't confuse controllers which depend on transfer chunk size as devices will report the rounded-up number, actually transfer that much and padding buffer is there to receive them. Signed-off-by: Tejun Heo [EMAIL PROTECTED] --- drivers/ata/libata-scsi.c | 35 --- 1 file changed, 32 insertions(+), 3 deletions(-) Index: work/drivers/ata/libata-scsi.c === --- work.orig/drivers/ata/libata-scsi.c +++ work/drivers/ata/libata-scsi.c @@ -2485,11 +2485,40 @@ static unsigned int atapi_xlat(struct at if (!using_pio ata_check_atapi_dma(qc)) using_pio = 1; - /* Some controller variants snoop this value for Packet transfers - to do state machine and FIFO management. Thus we want to set it - properly, and for DMA where it is effectively meaningless */ + /* Some controller variants snoop this value for Packet +* transfers to do state machine and FIFO management. Thus we +* want to set it properly, and for DMA where it is +* effectively meaningless. +*/ nbytes = min(qc-nbytes, (unsigned int)63 * 1024); + /* Most ATAPI devices which honor transfer chunk size don't +* behave according to the spec when odd chunk size which +* matches the transfer length is specified. If the number of +* bytes to transfer is 2n+1. According to the spec, what +* should happen is to indicate that 2n+1 is going to be +* transferred and transfer 2n+2 bytes where the last byte is +* padding. +* +* In practice, this doesn't happen. ATAPI devices first +* indicate and transfer 2n bytes and then indicate and +* transfer 2 bytes where the last byte is padding. +* +* This inconsistency confuses several controllers which +* perform PIO using DMA such as Intel AHCIs and sil3124/32. +* These controllers use actual number of transferred bytes to +* update DMA poitner and transfer of 4n+2 bytes make those +* controller push DMA pointer by 4n+4 bytes because SATA data +* FISes are aligned to 4 bytes. This causes data corruption +* and buffer overrun. +* +* Always setting nbytes to even number solves this problem +* because then ATAPI devices don't have to split data at 2n +* boundaries. +*/ + if (nbytes 0x1) + nbytes++; + qc-tf.lbam = (nbytes 0xFF); qc-tf.lbah = (nbytes 8); - 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: [PATCH RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
On Mon, 26 Nov 2007 20:34:38 +0900, Tejun Heo wrote:
Make pdc_atapi_pkt() use values from qc-tf instead of creating its
own. This is to ease future ATAPI handling changes.
DONT APPLY YET
---
Mikael, would this work? Values other than lbam and lbah remain the
same. Does sata_promise have strict requirements for lbam and lbah?
...
/* set feature and byte counter registers */
- if (qc-tf.protocol != ATA_PROT_ATAPI_DMA) {
+ if (qc-tf.protocol != ATA_PROT_ATAPI_DMA)
feature = PDC_FEATURE_ATAPI_PIO;
- /* set byte counter register to real transfer byte count */
- nbytes = qc-nbytes;
- if (nbytes 0x)
- nbytes = 0x;
- } else {
+ else
feature = PDC_FEATURE_ATAPI_DMA;
- /* set byte counter register to 0 */
- nbytes = 0;
- }
+
buf[20] = (1 5) | ATA_REG_FEATURE;
buf[21] = feature;
buf[22] = (1 5) | ATA_REG_BYTEL;
- buf[23] = nbytes 0xFF;
+ buf[23] = qc-tf.lbam;
buf[24] = (1 5) | ATA_REG_BYTEH;
- buf[25] = (nbytes 8) 0xFF;
+ buf[25] = qc-tf.lbah;
The original code matches what Promise' own driver does, including
the set byte counter register to real transfer byte count comment.
It's certainly possible that if lbah/lbam don't match -nbytes,
the HW will go nuts. Their data sheets are very quiet about ATAPI.
I can test your proposed change next weekend when I'm back to where
my sata_promise test equipment is.
/Mikael
-
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: Possibly SATA related freeze killed networking and RAID
Hi! kernel: [734344.717844] irq 21: nobody cared (try booting with the irqpoll option) kernel: [734344.717866] Your machine decided to emit interrupt 21 without an apparent reason. Whatever caused that made the kernel shut down IRQ 21 at which point the disk drives on that IRQ were no longer being serviced. Everything on IRQ 21 would have died - which may be why your networking failed too. Hmm, perhaps that 'nobody cared' message should be worded more strongly, and printed and KERN_CRIT? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: [PATCH RFC] sata_promise: make pdc_atapi_pkt() use values from qc-tf
Hello, Mikael Pettersson wrote: buf[20] = (1 5) | ATA_REG_FEATURE; buf[21] = feature; buf[22] = (1 5) | ATA_REG_BYTEL; -buf[23] = nbytes 0xFF; +buf[23] = qc-tf.lbam; buf[24] = (1 5) | ATA_REG_BYTEH; -buf[25] = (nbytes 8) 0xFF; +buf[25] = qc-tf.lbah; The original code matches what Promise' own driver does, including the set byte counter register to real transfer byte count comment. It's certainly possible that if lbah/lbam don't match -nbytes, the HW will go nuts. Their data sheets are very quiet about ATAPI. Yeah, now core code sets the value properly and I just posted a patch to massage transfer chunk size a bit so I was curious whether now sata_promise can use the result of core layer instead. I can test your proposed change next weekend when I'm back to where my sata_promise test equipment is. Thank you. -- tejun - 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: [PATCH] pata_pcmcia: Minor cleanups and support for dual channel cards
setup and it821x fixes can go to mainstream for 2.6.25 I think - no bad reports yet. BTW so we don't duplicate work right now I'm working on a full DMA engine based driver for the INIC162x. Dunno if I'll ever get it to work as the docs are a bit minimal but we shall see. - 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: [PATCH #upstream-fixes] libata: bump transfer chunk size if it's odd
Tejun Heo wrote: None of the drives I have follows what the standard says about transfer chunk size. Of the four SATA and six PATA ATAPI devices tested, four ignore transfer chunk size completely and the ones which honor it don't behave according to the spec when it's odd. According to the spec, transfer chunk size can be odd if the amount of data to transfer equals or is smaller than the chunk size and the device can indicate the same odd number and transfer the whole thing at one go with a pad byte appended. However, in reality, none of the drives I have does that. They all indicate and transfer even number of bytes one byte shorter than the chunk size first; then indicate and transfer two bytes, which is clearly out of spec. In addition to unnecessary second PIO data phase, this also creates a weird problem when combined with SATA controllers which perform PIO via DMA. Some of these controllers use actualy number of bytes received to update DMA pointer so chunks which are sized 4n + 2 makes DMA pointer off by two bytes. This causes data corruption and buffer overruns. This patch rounds nbytes up to the nearest even number such that ATAPI devices don't split data transfer for the last odd byte. This shouldn't confuse controllers which depend on transfer chunk size as devices will report the rounded-up number, actually transfer that much and padding buffer is there to receive them. Signed-off-by: Tejun Heo [EMAIL PROTECTED] applied - 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: [PATCH] [libata] Return proper ATA INT status in pata_bf54x driver.
sonic zhang wrote: INT status can be OR. Signed-off-by: Sonic Zhang [EMAIL PROTECTED] --- drivers/ata/pata_bf54x.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) applied - 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
[git patches] libata fixes
NOTE: This includes 100% of the fixes collected during the week I
was on vacation, by Tejun... rebased. So all the commit ids are
different from his push.
If you have not pulled from Tejun, then pull this.
If you have pulled from Tejun, then do not pull this (I will rebase once
Tejun's pull is pushed out).
Other notes: I have a sata_nv ATAPI fix that needs to go in too, should
push that in the next push (day or two).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ata_piix.c | 93 ++
drivers/ata/libata-core.c | 108 ++--
drivers/ata/libata-eh.c| 95 --
drivers/ata/libata-scsi.c | 38 ++--
drivers/ata/pata_ali.c | 20
drivers/ata/pata_bf54x.c |6 +-
drivers/ata/pata_hpt37x.c |2 +-
drivers/ata/pata_isapnp.c | 11 +++--
drivers/ata/pata_jmicron.c |9 ++--
drivers/ata/pata_sil680.c | 32 +
drivers/ata/pata_sis.c |1 +
drivers/ata/sata_sil24.c | 26 +-
include/linux/libata.h |5 +--
13 files changed, 184 insertions(+), 262 deletions(-)
Adrian Bunk (1):
libata: remove unused functions
Alan Cox (6):
ata_piix: Invalid use of writel/readl with iomap
libata-core: List more documentation sources for reference
pata_ali: Add Mitac 8317 and derivatives
pata_ali: Lots of problems still showing up with small ATAPI DMA
pata_hpt37x: Fix cable detect bug spotted by Sergei
pata_isapnp: Polled devices
Albert Lee (2):
libata: workaround DRQ=1 ERR=1 for ATAPI tape drives
libata: use ATA_HORKAGE_STUCK_ERR for ATAPI tape drives
Gabriel C (1):
pata_sis.c: Add Packard Bell EasyNote K5305 to laptops
Jeff Garzik (1):
pata_ali: trim trailing whitespace (fix checkpatch complaints)
Mark Lord (1):
libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs
Sergei Shtylyov (1):
pata_sil680: kill bogus reset code (take 2)
Tejun Heo (6):
ata_piix: add SATELLITE U205 to broken suspend list
ata_piix: reorganize controller IDs
ata_piix: port enable for the first SATA controller of ICH8 is 0xf not 0x3
pata_jmicron: fix disabled port handling in jmicron_pre_reset()
sata_sil24: fix sg table sizing
libata: bump transfer chunk size if it's odd
Thomas Rohwer (1):
ata_piix: only enable the first port on apple macbook pro
sonic zhang (1):
libata: Return proper ATA INT status in pata_bf54x driver
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 328ce8a..483269d 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -119,18 +119,19 @@ enum {
PIIX_80C_SEC= (1 7) | (1 6),
/* controller IDs */
- piix_pata_33= 0,/* PIIX4 at 33Mhz */
- ich_pata_33 = 1,/* ICH up to UDMA 33 only */
- ich_pata_66 = 2,/* ICH up to 66 Mhz */
- ich_pata_100= 3,/* ICH up to UDMA 100 */
- ich5_sata = 5,
- ich6_sata = 6,
- ich6_sata_ahci = 7,
- ich6m_sata_ahci = 8,
- ich8_sata_ahci = 9,
- piix_pata_mwdma = 10, /* PIIX3 MWDMA only */
- tolapai_sata_ahci = 11,
- ich9_2port_sata = 12,
+ piix_pata_mwdma = 0,/* PIIX3 MWDMA only */
+ piix_pata_33, /* PIIX4 at 33Mhz */
+ ich_pata_33,/* ICH up to UDMA 33 only */
+ ich_pata_66,/* ICH up to 66 Mhz */
+ ich_pata_100, /* ICH up to UDMA 100 */
+ ich5_sata,
+ ich6_sata,
+ ich6_sata_ahci,
+ ich6m_sata_ahci,
+ ich8_sata_ahci,
+ ich8_2port_sata,
+ ich8m_apple_sata_ahci, /* locks up on second port enable */
+ tolapai_sata_ahci,
/* constants for mapping table */
P0 = 0, /* port 0 */
@@ -239,19 +240,21 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* SATA Controller 1 IDE (ICH8) */
{ 0x8086, 0x2820, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
/* SATA Controller 2 IDE (ICH8) */
- { 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich9_2port_sata },
+ { 0x8086, 0x2825, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* Mobile SATA Controller IDE (ICH8M) */
{ 0x8086, 0x2828, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
+ /* Mobile SATA Controller IDE (ICH8M), Apple */
+ { 0x8086, 0x2828, 0x106b, 0x00a0, 0, 0, ich8m_apple_sata_ahci },
/* SATA Controller IDE (ICH9) */
{ 0x8086, 0x2920, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_ahci },
/* SATA Controller IDE (ICH9) */
- { 0x8086,
Re: [PATCH 2/2] ide-scsi: use print_hex_dump from linux/kernel.h
Matthew Wilcox wrote: On Mon, Nov 26, 2007 at 04:37:50PM +0800, rae l wrote: I know this is different from the original hexdump in ide-scsi.c, I just want to tell someone that there's a good implementation of hexdump in kernel.h, and I think the default KERN_DEBUG and print_hex_dump is more informative and has better output. However, anyone want more precise control on debug message could make her/his improvements with print_hex_dump. using KERN_DEBUG is wrong -- this is part of a line, so you need to use KERN_NONE or simply . s/KERN_NONE/KERN_CONT/ for continuation lines. -- ~Randy - 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: kernel bugzilla is FPOS (was: Re: buggy cmd640 message followed by soft lockup)
On Mon, Nov 26, 2007 at 01:30:06AM +0100, Rafael J. Wysocki wrote: On Monday, 26 of November 2007, Adrian Bunk wrote: ... That's not possible, but as already said it's not required. And more important, it's unrelated to any problems we have. And it sounds funny that you first write specifications mandating stuff like IMO, first, it should ask for what the bug is against and then demand an additional email interface that bypasses everything you demanded previously. I just realize that there are people who wouldn't like to use the web interface and would prefer to use email instead. In the cases where these are kernel developers that do (or should) handle dozens of bugs each week I see a point if they have problems integrating some medium into their workflow. But in all software, no matter whether open source or commercial, bug reporters simply have to use whatever the vendor offers as support channel. Moreover, you won't force people to use the web interface only for reporting bugs, because frankly for some kinds of problems it's too heavywieght That developers who know what they are doing might bypass the bug tracking is not a problem. (compilation problems and purely software, reproducible things like that are much faster resolved using email; this also applies to easily reproducible bugs in general). Still, it wouldn't hurt if they were automatically tracked. This sounds like a bit pregnant... Tracking requires things like e.g. categorizing the issue and marking it as fixed when it got fixed. Also, if you switch to email, and then want to switch back to the web interface, the Cc list from the email messages will be lost. The perfect is the enemy of the good. Sure. Greetings, Rafael cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: kernel bugzilla is FPOS (was: Re: buggy cmd640 message followed by soft lockup)
On Monday, 26 of November 2007, Adrian Bunk wrote: On Mon, Nov 26, 2007 at 01:30:06AM +0100, Rafael J. Wysocki wrote: On Monday, 26 of November 2007, Adrian Bunk wrote: ... That's not possible, but as already said it's not required. And more important, it's unrelated to any problems we have. And it sounds funny that you first write specifications mandating stuff like IMO, first, it should ask for what the bug is against and then demand an additional email interface that bypasses everything you demanded previously. I just realize that there are people who wouldn't like to use the web interface and would prefer to use email instead. In the cases where these are kernel developers that do (or should) handle dozens of bugs each week I see a point if they have problems integrating some medium into their workflow. But in all software, no matter whether open source or commercial, bug reporters simply have to use whatever the vendor offers as support channel. Yes. That's why we should tell them what the channel is. :-) Moreover, you won't force people to use the web interface only for reporting bugs, because frankly for some kinds of problems it's too heavywieght That developers who know what they are doing might bypass the bug tracking is not a problem. (compilation problems and purely software, reproducible things like that are much faster resolved using email; this also applies to easily reproducible bugs in general). Still, it wouldn't hurt if they were automatically tracked. This sounds like a bit pregnant... Tracking requires things like e.g. categorizing the issue and marking it as fixed when it got fixed. Yes, but that may be done after the fact. It's not a big problem to review an email thread starting from a bug report and see if it lead to a fix (I do that on a regular basis). [Note: They tend to be relatively short. ] You can even check if the fix has been merged. Still, you need to know which threads to review. Greetings, Rafael - 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
[PATCH] [libata] Set proper ATA UDMA mode for bf548 according to system clock.
UDMA Mode - Frequency compatibility
UDMA5 - 100 MB/s - SCLK = 133 MHz
UDMA4 - 66 MB/s- SCLK = 80 MHz
UDMA3 - 44.4 MB/s - SCLK = 50 MHz
UDMA2 - 33 MB/s- SCLK = 40 MHz
Signed-off-by: Sonic Zhang [EMAIL PROTECTED]
---
drivers/ata/pata_bf54x.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c
index 81db405..088a41f 100644
--- a/drivers/ata/pata_bf54x.c
+++ b/drivers/ata/pata_bf54x.c
@@ -1489,6 +1489,8 @@ static int __devinit bfin_atapi_probe(st
int board_idx = 0;
struct resource *res;
struct ata_host *host;
+ unsigned int fsclk = get_sclk();
+ int udma_mode = 5;
const struct ata_port_info *ppi[] =
{ bfin_port_info[board_idx], NULL };
@@ -1507,6 +1509,11 @@ static int __devinit bfin_atapi_probe(st
if (res == NULL)
return -EINVAL;
+ while (bfin_port_info[board_idx].udma_mask0 udma_fsclk[udma_mode]
fsclk) {
+ udma_mode--;
+ bfin_port_info[board_idx].udma_mask = 1;
+ }
+
/*
* Now that that's out of the way, wire up the port..
*/
--
1.4.3.4
-
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
