Bug 611350 - ATA frozen , random pauses, every disk (workaround: pcie_aspm=off)
ATA frozen , random pauses, every disk (workaround: pcie_aspm=off)
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
14
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-04 18:55 EDT by Reartes Guillermo
Modified: 2013-01-10 03:10 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-30 14:41:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
messages & some comments (1.26 KB, text/plain)
2010-07-04 18:55 EDT, Reartes Guillermo
no flags Details
messages new i/o error (121.16 KB, text/plain)
2010-07-21 22:30 EDT, Reartes Guillermo
no flags Details
original commented messages (60.94 KB, text/plain)
2010-07-27 20:21 EDT, Reartes Guillermo
no flags Details
deailled current messages full of sata errors (561.35 KB, application/octet-stream)
2010-07-27 20:22 EDT, Reartes Guillermo
no flags Details
messages from tests with noncq noapic nomsi (1.76 MB, text/plain)
2010-08-04 21:32 EDT, Reartes Guillermo
no flags Details
Fedora messages corresponding to the last test (180.72 KB, text/plain)
2010-08-06 21:47 EDT, Reartes Guillermo
no flags Details
Messages with 2.6.34.2 (81.44 KB, text/plain)
2010-08-09 16:21 EDT, Reartes Guillermo
no flags Details
lspci -vvv from F15 Alpha (28.02 KB, text/plain)
2011-03-10 07:22 EST, Reartes Guillermo
no flags Details

  None (edit)
Description Reartes Guillermo 2010-07-04 18:55:29 EDT
Created attachment 429439 [details]
messages & some comments

Description of problem: 

ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x400000 action 0x6 frozen
ata1.00: irq_stat 0x08000000, interface fatal error

System pauses for about a minute and then continues.

Version-Release number of selected component (if applicable): 
See attachment.

How reproducible:
Before or after the login screen, at leas one time every boot, and when performing high disk i/o. on any sata disk.

Steps to Reproduce:
1. boot the system
2. system becomes unresponsive for about a minute, then contiues normally.
3. check /var/log/messages for errors (ATA frozen errors)
  
Actual results:
random one minute pauses

Expected results:

Additional info:
Se attachment.
Comment 1 Reartes Guillermo 2010-07-10 23:14:06 EDT

Recently performed a 9Gb bulk copy and the filesystem was remounted read-only.
(/data filesystem) No data loss for now.
Comment 2 Reartes Guillermo 2010-07-21 22:30:32 EDT
Created attachment 433570 [details]
messages new i/o error


Just performed a 1 GB copy from sda1 (ntfs) to sda6 (reiserfs) and it failed with I/O error , resulting in sda6 remounted read-only. I had to umount & remount it. See attachment.

I own 4 hard disks, 2 x 1TB WD black, 1 x 500GB WD blue (eSATA) backup and 1 x 2TB WD green (eSATA) WDTV, all hard drives experienced both "ata bus error" and "timeouts". And now Ï/O error. 

I will uninstall fedora and reinstall Slackware to perform some tests (to discard that the sata controller faulted or got destroyed on the first fedora boot, since there is no problem with WinXP).

I also noticed that de dvd-rw (sata) performs prety lame also. (8-10mb and a lot of noise reading dvds).

I will post again after the results.
Comment 3 Reartes Guillermo 2010-07-27 19:39:27 EDT

I performed the following tests with slack64 13.1:
* copy 64gb from sda to sdb (no-errors)
* copy 64gb from sdb to sda (no-errors)

Then i reinstalled Fedora 13.1 X86_64 & performed a yum update.
During the install phase, errors were issued.

by "errors" i mean:
ata1.00: exception Emask 0x10 SAct 0x1 SErr 0x400000 action 0x6 frozen
ata1.00: irq_stat 0x08000000, interface fatal error

I noticed that i attached the wrong file in my first post somehow, i will attach a correct dmesg file.
Comment 4 Reartes Guillermo 2010-07-27 19:55:32 EDT
Hardware Configuration:

[root@ulquiorra ~]# uname -a
Linux ulquiorra.espada 2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[root@ulquiorra ~]# cat /etc/fedora-release 
Fedora release 13 (Goddard)
[root@ulquiorra ~]# lspci
00:00.0 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP78S [GeForce 8200] LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP78S [GeForce 8200] SMBus (rev a1)
00:01.2 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:01.3 Co-processor: nVidia Corporation MCP78S [GeForce 8200] Co-Processor (rev a2)
00:01.4 RAM memory: nVidia Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:02.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:06.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] IDE (rev a1)
00:08.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:09.0 SATA controller: nVidia Corporation MCP78S [GeForce 8200] AHCI Controller (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation MCP77 Ethernet (rev a2)
00:10.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:13.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:14.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
01:09.0 Multimedia audio controller: Creative Labs CA0106 Soundblaster
01:0a.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0)
02:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2)
02:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev a1)
[root@ulquiorra ~]#  cat /sys/devices/virtual/dmi/id/board_name 
M4N72-E
[root@ulquiorra ~]# cat /sys/devices/virtual/dmi/id/bios_version 
0205   
[root@ulquiorra ~]# hdparm -Q /dev/sd[a-b]

/dev/sda:
 queue_depth   = 31

/dev/sdb:
 queue_depth   = 31
[root@ulquiorra ~]# hdparm /dev/sd[a-b]

/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 121601/255/63, sectors = 1953525168, start = 0

/dev/sdb:
 multcount     = 16 (on)
 IO_support    =257 (???)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 121601/255/63, sectors = 1953525168, start = 0
[root@ulquiorra ~]#
Comment 5 Reartes Guillermo 2010-07-27 20:21:29 EDT
Created attachment 434882 [details]
original commented messages
Comment 6 Reartes Guillermo 2010-07-27 20:22:49 EDT
Created attachment 434883 [details]
deailled current messages full of sata errors
Comment 7 Chuck Ebbert 2010-08-01 14:34:13 EDT
(In reply to comment #3)
> 
> I performed the following tests with slack64 13.1:
> * copy 64gb from sda to sdb (no-errors)
> * copy 64gb from sdb to sda (no-errors)
> 

And what kernel version does that have?
Comment 8 Reartes Guillermo 2010-08-04 21:29:19 EDT
These tests were performed at 2010-07-30

---------------------------------------------

These commands allways triger the error(s)
These commands were used in the tests below.

# dd if=/dev/sda of=/dev/null bs=20M &
# dd if=/dev/sdb of=/dev/null bs=20M &
# badblocks /dev/sdb6 &>/dev/null &
# badblocks /dev/sda6 &>/dev/null &
# echo "3" > /proc/sys/vm/drop_caches
# find / &>/dev/null 
# yum list installed

----------------------------------------------

Slackware64 13.1 kernel	2.6.33.4
Slackware 13.0 kernel 2.6.29.6

Slackware64 13.1	Fedora 13 X86_64
----------------------------------------
mdadm 2.6.4		mdadm 3.1.2


Firmware Updates:

DVD-RW: (ASUS DRW-20B1LT)
original: 1.00
current:  1.01

Motherboard (M4N72-E)
Original: 0205
Current:  2005

After updating, the problem persist.


-------------------------------------------------------------

Physical Devices Conected	
Port 1	WDC 1TB BLACK
Port 3	WDC 1TB BLACK

Fedora 13 X86_64	2.6.33.6-147.fc13.x86_64						
Mode	NCQ			Link Speed		DMA Usage	MSI Usage	APIC Usage	MDADM		Errors?
--------------------------------------------------------------------------------------------------------------------------------------
AHCI	AUTO NCQ (default)	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	YES		YES	many
AHCI	libata.force=noncq	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	YES		YES	many
AHCI	AUTO NCQ (default)	libata.force=1.5G	DMA (default)	MSI (default)	APIC (default)	YES		YES	few
AHCI	libata.force=noncq	libata.force=1.5G	DMA (default)	MSI (default)	APIC (default)	YES		YES	few
AHCI	libata.force=noncq	libata.force=1.5G	libata.dma=0	MSI (default)	APIC (default)	YES		YES	few
AHCI	libata.force=noncq	libata.force=1.5G	libata.dma=0	pci=nomsi	APIC (default)	YES		YES	few
AHCI	libata.force=noncq	libata.force=1.5G	libata.dma=0	pci=nomsi	noapic		YES		YES	few
IDE	libata.force=noncq	libata.force=1.5G	libata.dma=0	pci=nomsi	noapic		YES		YES	few
IDE	libata.force=noncq	libata.force=1.5G	libata.dma=0	pci=nomsi	APIC (default)	YES		YES	few
IDE	libata.force=noncq	libata.force=1.5G	libata.dma=0	MSI (default)	APIC (default)	YES		YES	few
IDE	libata.force=noncq	libata.force=1.5G	DMA (default)	MSI (default)	APIC (default)	YES		YES	few
IDE	libata.force=noncq	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	YES		YES	many
IDE	AUTO NCQ (default)	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	YES		YES	many
IDE	AUTO NCQ (default)	libata.force=1.5G	DMA (default)	MSI (default)	APIC (default)	YES		YES	many
IDE	AUTO NCQ (default)	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	rd_NO_MD	YES	many
AHCI	AUTO NCQ (default)	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	rd_NO_MD	YES	many






-------------------------------------------------------------------------------------------------------

I performed another test (actually very short), with the following
disks (different disks, on the same computer)

Physical Devices Conected	
Port 1	WDC 1200JS *This device does not support NCQ
Port 3	WDC 5000AAKS

SLACKWARE 13.0 i386	2.6.29.6						
Mode	NCQ 			Link Speed		DMA Usage	MSI Usage	APIC Usage	MDADM		Errors?
AHCI	AUTO NCQ (default)	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	NO		NO
								
Fedora 13 X86_64	2.6.33.3-85.fc13.x86_64						
Mode	NCQ 			Link Speed		DMA Usage	MSI Usage	APIC Usage	MDADM		Errors?
AHCI	AUTO NCQ (default)	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	NO		YES
								
Fedora 13 i386		kernel stock						
Mode	NCQ 			Link Speed		DMA Usage	MSI Usage	APIC Usage	MDADM		Errors?
AHCI	AUTO NCQ (default)	AUTO SPEED (default)	DMA (default)	MSI (default)	APIC (default)	NO		YES

-------------------------------------------------------------------------

Recenly upgraded to 2.6.33.6-147.2.4.fc13.x86_64

a simple find trigers the errors.
# echo "3" > /proc/sys/vm/drop_caches
# find /&>/dev/null&
Comment 9 Reartes Guillermo 2010-08-04 21:32:53 EDT
Created attachment 436710 [details]
messages from tests with noncq noapic nomsi
Comment 10 Reartes Guillermo 2010-08-04 21:50:47 EDT
It is the same post, but a bit better formated.


These tests were performed at 2010-07-30

---------------------------------------------

These commands allways triger the error(s)
These commands were used in the tests below.

# dd if=/dev/sda of=/dev/null bs=20M &
# dd if=/dev/sdb of=/dev/null bs=20M &
# badblocks /dev/sdb6 &>/dev/null &
# badblocks /dev/sda6 &>/dev/null &
# echo "3" > /proc/sys/vm/drop_caches
# find / &>/dev/null 
# yum list installed

----------------------------------------------

Slackware64 13.1 kernel	2.6.33.4
Slackware 13.0 kernel 2.6.29.6

Slackware64 13.1	Fedora 13 X86_64
----------------------------------------
mdadm 2.6.4		mdadm 3.1.2


Firmware Updates:

DVD-RW: (ASUS DRW-20B1LT)
original: 1.00
current:  1.01

Motherboard (M4N72-E)
Original: 0205
Current:  2005

After updating, the problem persist.


-------------------------------------------------------------

Physical Devices Conected
Port 1  WDC 1TB BLACK
Port 3  WDC 1TB BLACK

Fedora 13 X86_64 (with 2.6.33.6-147.fc13.x86_64)						
Mode  NCQ                 Link Speed           DMA Usage     MSI Usage      APIC Usage      MDADM     Errors?
--------------------------------------------------------------------------------------------------------------
AHCI  AUTO NCQ (default)  AUTO SPEED(default)  DMA(default)  MSI (default)  APIC (default)  YES       YES many
AHCI  libata.force=noncq  AUTO SPEED(default)  DMA(default)  MSI (default)  APIC (default)  YES       YES many
AHCI  AUTO NCQ (default)  libata.force=1.5G    DMA(default)  MSI (default)  APIC (default)  YES       YES few
AHCI  libata.force=noncq  libata.force=1.5G    DMA(default)  MSI (default)  APIC (default)  YES       YES few
AHCI  libata.force=noncq  libata.force=1.5G    libata.dma=0  MSI (default)  APIC (default)  YES       YES few
AHCI  libata.force=noncq  libata.force=1.5G    libata.dma=0  pci=nomsi      APIC (default)  YES       YES few
AHCI  libata.force=noncq  libata.force=1.5G    libata.dma=0  pci=nomsi      noapic          YES       YES few
IDE   libata.force=noncq  libata.force=1.5G    libata.dma=0  pci=nomsi      noapic          YES       YES few
IDE   libata.force=noncq  libata.force=1.5G    libata.dma=0  pci=nomsi      APIC (default)  YES       YES few
IDE   libata.force=noncq  libata.force=1.5G    libata.dma=0  MSI (default)  APIC (default)  YES       YES few
IDE   libata.force=noncq  libata.force=1.5G    DMA(default)  MSI (default)  APIC (default)  YES       YES few
IDE   libata.force=noncq  AUTO SPEED(default)  DMA(default)  MSI (default)  APIC (default)  YES	      YES many
IDE   AUTO NCQ (default)  AUTO SPEED(default)  DMA(default)  MSI (default)  APIC (default)  YES	      YES many
IDE   AUTO NCQ (default)  libata.force=1.5G    DMA(default)  MSI (default)  APIC (default)  YES       YES many
IDE   AUTO NCQ (default)  AUTO SPEED(default)  DMA(default)  MSI (default)  APIC (default)  rd_NO_MD  YES many
AHCI  AUTO NCQ (default)  AUTO SPEED(default)  DMA(default)  MSI (default)  APIC (default)  rd_NO_MD  YES many


-------------------------------------------------------------------------------------------------------

I performed another test (actually very short), with the following
disks (different disks, on the same computer)

Physical Devices Conected	
Port 1	WDC 1200JS *This device does not support NCQ
Port 3	WDC 5000AAKS

SLACKWARE 13.0 i386  (with 2.6.29.6)
Mode  NCQ                Link Speed           DMA Usage     MSI Usage	  APIC Usage      MDADM   Errors?
AHCI  AUTO NCQ(default)  AUTO SPEED(default)  DMA(default)  MSI(default)  APIC (default)  NO      NO
								
Fedora 13 X86_64  (with 2.6.33.3-85.fc13.x86_64)						
Mode  NCQ                Link Speed           DMA Usage	    MSI Usage	  APIC Usage	 MDADM	  Errors?
AHCI  AUTO NCQ(default)  AUTO SPEED(default)  DMA(default)  MSI(default)  APIC(default)  NO       YES
								
Fedora 13 i386 (with kernel stock version)					
Mode  NCQ                Link Speed           DMA Usage     MSI Usage     APIC Usage     MDADM    Errors?
AHCI  AUTO NCQ(default)  AUTO SPEED(default)  DMA(default)  MSI(default)  APIC(default)  NO       YES

---------------------------------------------------------------------------------------------------------

Recenly upgraded to 2.6.33.6-147.2.4.fc13.x86_64

a simple find trigers the errors.
# echo "3" > /proc/sys/vm/drop_caches
# find /&>/dev/null&
Comment 11 Reartes Guillermo 2010-08-06 21:45:50 EDT
Today i tried RHEL 6.0b2 (with 2.6.32-37.el6.x86_64) and it also
suffered from the same issues. (ata frozen / timeout / ata bus error)

Tried disabling mdmonitor, but it does not change anything (RHEL 6.0b2)

I set up a permanent partition in sdb and installed Slackware64 13.1
for further testing. (alongside Fedora 13.1 x86_64 in sda)

Testing Slackware64 with the following commands:

# dd if=/dev/sda of=/dev/null bs=20M &
# dd if=/dev/sdb of=/dev/null bs=20M &
# badblocks /dev/sdb6 &>/dev/null &
# badblocks /dev/sda6 &>/dev/null &
# echo "3" > /proc/sys/vm/drop_caches
# find / &>/dev/null &


And simultaneously created a backup for the home filesystem (/dev/md127)

# mkdir /mnt/hd/home-tar
# cd /mnt/hd/home-tar
# tar cf home.tar /home/

And simultaneously also

# dd if=/dev/md127 of=/dev/null bs=20M &>/dev/null &
# echo "3" > /proc/sys/vm/drop_caches
# find / &>/dev/null &

I was not able to reproduce the problem with Slackware64 13.1 (There
were no messages and no pauses for more than 3 hours)

In Fedora 13 x86_64 (with 2.6.33.6-147.2.4.fc13.x86_64)

# dd if=/dev/sda of=/dev/null bs=20M &>dd-sda.out &
# dd if=/dev/sdb of=/dev/null bs=20M &>dd-sdb.out &
# dd if=/dev/md127 of=/dev/null bs=20M &>dd-md127.out &
# badblocks /dev/sdb6 &>/dev/null &
# badblocks /dev/sda6 &>/dev/null &
# echo "3" > /proc/sys/vm/drop_caches
# find / &>/dev/null &
# dd if=/dev/sda of=/dev/null bs=20M &>dd-sda-bis.out &
# dd if=/dev/sdb of=/dev/null bs=20M &>dd-sdb-bis.out &
# dd if=/dev/md127 of=/dev/null bs=20M &>dd-md127-bis.out &

Got lots of the usual errors, and even an I/O error (in less than 20 minutes).


Comparing the boot of Fedora, RHEL and Slackware:

Fedora 13 (x86_64)
-------------------------------------------------
Aug  6 21:11:55 ulquiorra kernel: ahci 0000:00:09.0: PCI INT A -> Link[LSA0] -> GSI 23 (level, low) -> IRQ 23
Aug  6 21:11:55 ulquiorra kernel: ahci 0000:00:09.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
Aug  6 21:11:55 ulquiorra kernel: ahci 0000:00:09.0: flags: 64bit ncq sntf led clo pmp pio boh 
Aug  6 21:11:55 ulquiorra kernel: scsi0 : ahci
Aug  6 21:11:55 ulquiorra kernel: scsi1 : ahci
Aug  6 21:11:55 ulquiorra kernel: scsi2 : ahci
Aug  6 21:11:55 ulquiorra kernel: scsi3 : ahci
Aug  6 21:11:55 ulquiorra kernel: scsi4 : ahci
Aug  6 21:11:55 ulquiorra kernel: scsi5 : ahci
Aug  6 21:11:55 ulquiorra kernel: ata1: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a100 irq 27
*Aug  6 21:11:55 ulquiorra kernel: ata2: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Aug  6 21:11:55 ulquiorra kernel: ata3: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a200 irq 27
*Aug  6 21:11:55 ulquiorra kernel: ata4: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Aug  6 21:11:55 ulquiorra kernel: ata5: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a300 irq 27
Aug  6 21:11:55 ulquiorra kernel: ata6: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a380 irq 27
Aug  6 21:11:55 ulquiorra kernel: scsi6 : pata_amd
Aug  6 21:11:55 ulquiorra kernel: scsi7 : pata_amd
Aug  6 21:11:55 ulquiorra kernel: ata7: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
Aug  6 21:11:55 ulquiorra kernel: ata8: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15


RHEL 6.0b2
---------------------------------------------------
Aug  6 16:56:51 stark kernel: scsi0 : pata_amd
Aug  6 16:56:51 stark kernel: scsi1 : pata_amd
Aug  6 16:56:51 stark kernel: ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
Aug  6 16:56:51 stark kernel: ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
Aug  6 16:56:51 stark kernel: ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
Aug  6 16:56:51 stark kernel: ahci 0000:00:09.0: PCI INT A -> Link[LSA0] -> GSI 23 (level, low) -> IRQ 23
Aug  6 16:56:51 stark kernel: ahci 0000:00:09.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
Aug  6 16:56:51 stark kernel: ahci 0000:00:09.0: flags: 64bit ncq sntf led clo pmp pio boh 
Aug  6 16:56:51 stark kernel: scsi2 : ahci
Aug  6 16:56:51 stark kernel: scsi3 : ahci
Aug  6 16:56:51 stark kernel: scsi4 : ahci
Aug  6 16:56:51 stark kernel: scsi5 : ahci
Aug  6 16:56:51 stark kernel: scsi6 : ahci
Aug  6 16:56:51 stark kernel: scsi7 : ahci
*Aug  6 16:56:51 stark kernel: ata3: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
*Aug  6 16:56:51 stark kernel: ata4: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Aug  6 16:56:51 stark kernel: ata5: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a200 irq 27
*Aug  6 16:56:51 stark kernel: ata6: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Aug  6 16:56:51 stark kernel: ata7: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a300 irq 27
Aug  6 16:56:51 stark kernel: ata8: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a380 irq 27

Slackware64 13.1
-----------------------------------------------------------
Aug  6 17:53:15 stark kernel: ahci 0000:00:09.0: PCI INT A -> Link[LSA0] -> GSI 23 (level, low) -> IRQ 23
Aug  6 17:53:15 stark kernel: ahci 0000:00:09.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
Aug  6 17:53:15 stark kernel: ahci 0000:00:09.0: flags: 64bit ncq sntf led clo pmp pio boh 
Aug  6 17:53:15 stark kernel: scsi0 : ahci
Aug  6 17:53:15 stark kernel: scsi1 : ahci
Aug  6 17:53:15 stark kernel: scsi2 : ahci
Aug  6 17:53:15 stark kernel: scsi3 : ahci
Aug  6 17:53:15 stark kernel: scsi4 : ahci
Aug  6 17:53:15 stark kernel: scsi5 : ahci
Aug  6 17:53:15 stark kernel: ata1: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a100 irq 27
Aug  6 17:53:15 stark kernel: ata2: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a180 irq 27
Aug  6 17:53:15 stark kernel: ata3: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a200 irq 27
Aug  6 17:53:15 stark kernel: ata4: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a280 irq 27
Aug  6 17:53:15 stark kernel: ata5: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a300 irq 27
Aug  6 17:53:15 stark kernel: ata6: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a380 irq 27
Aug  6 17:53:15 stark kernel: scsi6 : pata_amd
Aug  6 17:53:15 stark kernel: scsi7 : pata_amd
Aug  6 17:53:15 stark kernel: ata7: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
Aug  6 17:53:15 stark kernel: ata8: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15


*=lines marked seems suspicius to me. Slackware output differs.

I may post slackware and rhel dmesg if necesary. 
I attach the last fedora messages.

I did not have the courage to test the following kernel parameters: 

libata.force=nohrst
libata.force=nosrst
libata.force=norst

Suppress hard, soft and both resets. I do not kwnow if it is a safe thing to do... But i am running out of ideas...
Comment 12 Reartes Guillermo 2010-08-06 21:47:33 EDT
Created attachment 437290 [details]
Fedora messages corresponding to the last test
Comment 13 Reartes Guillermo 2010-08-07 15:33:49 EDT
Tested CentOS 5.5 X86-64

Centos 5.5 X86-64 (with stock and 2.6.18-194.el5)

# dd if=/dev/sda of=/dev/null bs=20M &
# dd if=/dev/sdb of=/dev/null bs=20M &
# badblocks /dev/sdb6 &>/dev/null &
# badblocks /dev/sda6 &>/dev/null &
# echo "3" > /proc/sys/vm/drop_caches
# find / &>/dev/null &

Aug  7 12:19:54 stark kernel: ahci 0000:00:09.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
Aug  7 12:19:54 stark kernel: ahci 0000:00:09.0: flags: 64bit ncq sntf led clo pmp pio 
Aug  7 12:19:54 stark kernel: scsi0 : ahci
Aug  7 12:19:54 stark kernel: scsi1 : ahci
Aug  7 12:19:54 stark kernel: scsi2 : ahci
Aug  7 12:19:54 stark kernel: scsi3 : ahci
Aug  7 12:19:54 stark kernel: scsi4 : ahci
Aug  7 12:19:54 stark kernel: scsi5 : ahci
Aug  7 12:19:54 stark kernel: ata1: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a100 irq 66
Aug  7 12:19:54 stark kernel: ata2: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a180 irq 66
Aug  7 12:19:54 stark kernel: ata3: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a200 irq 66
Aug  7 12:19:54 stark kernel: ata4: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a280 irq 66
Aug  7 12:19:54 stark kernel: ata5: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a300 irq 66
Aug  7 12:19:54 stark kernel: ata6: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a380 irq 66

CentOS 5.5 does not suffer from the problem. The " ata1: SATA max UDMA/133 abar" stuff is
similar to Slackware64 13.1 and different from RHEL 6.0b2 and FC 13. (marked with * in my previous
post)
Comment 14 Chuck Ebbert 2010-08-08 20:54:37 EDT
Did you try the 2.6.34.2 kernel from f13 updates-testing?
Comment 15 Reartes Guillermo 2010-08-09 16:19:08 EDT
Thanks for the advice.
I Upgraded to 2.6.34.2-34.fc13.x86_64 from updates-testing and
the issue is still there :-(

Aug  9 16:52:28 ulquiorra kernel: ahci 0000:00:09.0: PCI INT A -> Link[LSA0] -> GSI 23 (level, low) -> IRQ 23
Aug  9 16:52:28 ulquiorra kernel: ahci 0000:00:09.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
Aug  9 16:52:28 ulquiorra kernel: ahci 0000:00:09.0: flags: 64bit ncq sntf led clo pmp pio boh 
Aug  9 16:52:28 ulquiorra kernel: scsi0 : ahci
Aug  9 16:52:28 ulquiorra kernel: scsi1 : ahci
Aug  9 16:52:28 ulquiorra kernel: scsi2 : ahci
Aug  9 16:52:28 ulquiorra kernel: scsi3 : ahci
Aug  9 16:52:28 ulquiorra kernel: scsi4 : ahci
Aug  9 16:52:28 ulquiorra kernel: scsi5 : ahci
* Aug  9 16:52:28 ulquiorra kernel: ata1: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
* Aug  9 16:52:28 ulquiorra kernel: ata2: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Aug  9 16:52:28 ulquiorra kernel: ata3: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a200 irq 27
* Aug  9 16:52:28 ulquiorra kernel: ata4: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Aug  9 16:52:28 ulquiorra kernel: ata5: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a300 irq 27
Aug  9 16:52:28 ulquiorra kernel: ata6: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a380 irq 27

The lines marked with * are different in both Slackware and Centos5.5, there are no 
"irq_stat 0x00000040, connection status changed" messages, as noted in my previous post.
Comment 16 Reartes Guillermo 2010-08-09 16:21:55 EDT
Created attachment 437700 [details]
Messages with 2.6.34.2
Comment 17 Reartes Guillermo 2010-09-02 18:08:12 EDT
I upgraded to 2.6.34.6-47.fc13.x86_64 and still afected by the same problem(s)
After login, dmesg shows:

ata2.00: exception Emask 0x10 SAct 0x1 SErr 0x400000 action 0x6 frozen
ata2.00: irq_stat 0x08000000, interface fatal error
ata2: SError: { Handshk }
ata2.00: failed command: WRITE FPDMA QUEUED
ata2.00: cmd 61/d0:00:6f:06:f9/00:00:04:00:00/40 tag 0 ncq 106496 out
         res 40/00:04:6f:06:f9/00:00:04:00:00/40 Emask 0x10 (ATA bus error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
ata2: EH complete
ata1.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 frozen
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/80:00:0d:bb:30/00:00:0f:00:00/40 tag 0 ncq 65536 in
         res 40/00:14:5d:87:d2/00:00:0e:00:00/40 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:08:78:0f:b0/00:00:0c:00:00/40 tag 1 ncq 4096 out
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/20:10:5d:81:f6/00:00:0e:00:00/40 tag 2 ncq 16384 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/20:18:35:54:ec/00:00:0e:00:00/40 tag 3 ncq 16384 in
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1.00: device reported invalid CHS sector 0
ata1.00: device reported invalid CHS sector 0
ata1.00: device reported invalid CHS sector 0
ata1: EH complete

Performing # find / &>/dev/null &

Sep  2 18:59:45 ulquiorra kernel: ata2.00: exception Emask 0x10 SAct 0x1f SErr 0x400000 action 0x6 frozen
Sep  2 18:59:45 ulquiorra kernel: ata2.00: irq_stat 0x08000000, interface fatal error
Sep  2 18:59:45 ulquiorra kernel: ata2: SError: { Handshk }
Sep  2 18:59:45 ulquiorra kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Sep  2 18:59:45 ulquiorra kernel: ata2.00: cmd 61/00:00:d2:60:f4/04:00:14:00:00/40 tag 0 ncq 524288 out
Sep  2 18:59:45 ulquiorra kernel:         res 40/00:1c:d2:5c:f4/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Sep  2 18:59:45 ulquiorra kernel: ata2.00: status: { DRDY }
Sep  2 18:59:45 ulquiorra kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Sep  2 18:59:45 ulquiorra kernel: ata2.00: cmd 61/00:08:d2:54:f4/04:00:14:00:00/40 tag 1 ncq 524288 out
Sep  2 18:59:45 ulquiorra kernel:         res 40/00:1c:d2:5c:f4/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Sep  2 18:59:45 ulquiorra kernel: ata2.00: status: { DRDY }
Sep  2 18:59:45 ulquiorra kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Sep  2 18:59:45 ulquiorra kernel: ata2.00: cmd 61/00:10:d2:58:f4/04:00:14:00:00/40 tag 2 ncq 524288 out
Sep  2 18:59:45 ulquiorra kernel:         res 40/00:1c:d2:5c:f4/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Sep  2 18:59:45 ulquiorra kernel: ata2.00: status: { DRDY }
Sep  2 18:59:45 ulquiorra kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Sep  2 18:59:45 ulquiorra kernel: ata2.00: cmd 61/00:18:d2:5c:f4/04:00:14:00:00/40 tag 3 ncq 524288 out
Sep  2 18:59:45 ulquiorra kernel:         res 40/00:1c:d2:5c:f4/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Sep  2 18:59:45 ulquiorra kernel: ata2.00: status: { DRDY }
Sep  2 18:59:45 ulquiorra kernel: ata2.00: failed command: WRITE FPDMA QUEUED
Sep  2 18:59:45 ulquiorra kernel: ata2.00: cmd 61/38:20:d2:64:f4/00:00:14:00:00/40 tag 4 ncq 28672 out
Sep  2 18:59:45 ulquiorra kernel:         res 40/00:1c:d2:5c:f4/00:00:14:00:00/40 Emask 0x10 (ATA bus error)
Sep  2 18:59:45 ulquiorra kernel: ata2.00: status: { DRDY }
Sep  2 18:59:45 ulquiorra kernel: ata2: hard resetting link
Sep  2 18:59:45 ulquiorra kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Sep  2 18:59:45 ulquiorra kernel: ata2.00: configured for UDMA/133
Sep  2 18:59:45 ulquiorra kernel: ata2: EH complete

This in really anoying, random pauses, random (but rare) read-only remounts, and
not so rare (but not common) forced mirror resyncs, even just plain I/O errors
ocasionally.
Comment 18 Chuck Ebbert 2010-09-03 05:43:58 EDT
ATA bus errors and handshake errors probably indicate some kind of hardware problem, possibly with the cables.
Comment 19 Reartes Guillermo 2010-09-03 08:08:46 EDT
I know, however, changing the operating system to Slackware / Centos (using the same cables) fixes the problem, this must be a bug. As i said earlier, i used slackware for more than half a year and only 'discovered' the isse the day i isntalled F13.

I will try to diff the source code (sata driver) used in slack and f13 (with the current kernel).
Comment 20 Chuck Ebbert 2010-09-04 08:30:11 EDT
You could try adding "pcie_aspm=off" to the boot options; other than that I don't think we have changed any defaults from the stock kernel.
Comment 21 Reartes Guillermo 2010-09-04 19:30:26 EDT
I WORKS!

It seems that pcie aspm does have a few issues..., i will keep it disabled.
I copied several files, performed some basic tests, for about 8 hours and the
total number of sata erros is CERO!  :-)


I still see "connection status changed" messages (both centos/slackware64 are free of these issues). These happen ONLY ONCE, uppon booting or when powering an external drive (esata). 

Sep  4 19:33:44 ulquiorra kernel: ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
Sep  4 19:33:44 ulquiorra kernel: ahci 0000:00:09.0: PCI INT A -> Link[LSA0] -> GSI 23 (level, low) -> IRQ 23
Sep  4 19:33:44 ulquiorra kernel: ahci 0000:00:09.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
Sep  4 19:33:44 ulquiorra kernel: ahci 0000:00:09.0: flags: 64bit ncq sntf led clo pmp pio boh 
Sep  4 19:33:44 ulquiorra kernel: scsi0 : ahci
Sep  4 19:33:44 ulquiorra kernel: scsi1 : ahci
Sep  4 19:33:44 ulquiorra kernel: scsi2 : ahci
Sep  4 19:33:44 ulquiorra kernel: scsi3 : ahci
Sep  4 19:33:44 ulquiorra kernel: scsi4 : ahci
Sep  4 19:33:44 ulquiorra kernel: scsi5 : ahci
Sep  4 19:33:44 ulquiorra kernel: ata1: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a100 irq 27
Sep  4 19:33:44 ulquiorra kernel: ata2: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Sep  4 19:33:44 ulquiorra kernel: ata3: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a200 irq 27
Sep  4 19:33:44 ulquiorra kernel: ata4: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Sep  4 19:33:44 ulquiorra kernel: ata5: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 27
Sep  4 19:33:44 ulquiorra kernel: ata6: SATA max UDMA/133 abar m8192@0xf9e7a000 port 0xf9e7a380 irq 27


I will post again i a few days, after performing more specific test.

Thanks for the advice!
Comment 22 Chuck Ebbert 2010-09-06 11:22:07 EDT
So now we have found PCIE ASPM causing errors in AHCI:

ata2.00: exception Emask 0x10 SAct 0x1 SErr 0x400000 action 0x6 frozen
ata2.00: irq_stat 0x08000000, interface fatal error
ata2: SError: { Handshk }
ata2.00: failed command: WRITE FPDMA QUEUED
ata2.00: cmd 61/d0:00:6f:06:f9/00:00:04:00:00/40 tag 0 ncq 106496 out
         res 40/00:04:6f:06:f9/00:00:04:00:00/40 Emask 0x10 (ATA bus error)
ata2.00: status: { DRDY }
Comment 23 Reartes Guillermo 2010-09-07 20:18:02 EDT
I can confirm that i have not experienced any more sata ahci errors since a couple of days. So using pcie_aspm=off is a valid workaround for the problem.
In fact, the disk performance is now on par with centos/slackware, more or less.

I wonder if it is a bug in the ahci (nvidia) or in the pcie_aspm code...

Should i open a new bugreport or simply keep this one?
Comment 24 Reartes Guillermo 2011-02-08 15:10:14 EST
Update:

This issue also afects Fedora 14:

F14, default kernel (LiveCD-KDE) ---> 2.6.35.6-45.fc14.x86_64


I installed F14 in another partition.
  (Now i have F13, F14 & Slackware64 13.1)
My main os is still F13. (Until F15)
Comment 25 Reartes Guillermo 2011-02-12 11:18:26 EST
I analysed what is different with or without pcie_aspm for the 
sata controller (lspci -vvv) and found that nothing changes!!!?!!


These device shows changes when comparing lspci -vvv with pcie_aspm and
without pcie_aspm. (using diff to compare the lspci -vvv outputs)

00:10.0 PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1) (prog-if 00 [Normal decode])
02:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2) (prog-if 00 [VGA controller])
02:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev a1)


So nothing changes in the sata controller, how does it cause problems to
have pcie_aspm enabled? Why does pcie_aspm=off fix anything at all?

May the problem be in the PCI bridge: nVidia Corporation MCP78S [GeForce 8200] PCI Express Bridge and not in the sata controller?

Note: (Allways using pcie_aspm=off) I also get random gpu lockus with novueau. 
And  also with the nVIDIA(P) drivers (260*=). 
And also get random gpu lockups with and ATI HD5670 with the Catalyst(P) driver. 

It is normal that disabling pcie_aspm causes the pcie bus to work at gen1 (halves link speed & the de-enphasis level? (have gen2 bus & card)
Comment 26 Reartes Guillermo 2011-03-10 07:19:51 EST
I installed F15 Alpha and performed some tests. 
It seems that F15 will rock when released! (I got very impressed by the good quality of this alpha)

kernels tested:
2.6.38-0.rc5.git1.1.fc15.x86_64 
2.6.38-0.rc8.git0.1.fc15.x86_64

Installed F15 Alpha from CDROM, then 

# dd if=/dev/sda of=/dev/null bs=20M &>/dev/null &
# dd if=/dev/sdb of=/dev/null bs=20M &>/dev/null &
# find / &>/dev/null &
# yum update

The disks where 100% busy for nearly an hour.

No errors where issued to /var/log/messages

Rebooted and tested again with the new kernel and 
also found no errors.

I did not use any special boot parameter, just default boot.
It seems that pcie_aspm is disabled by default.
Comment 27 Reartes Guillermo 2011-03-10 07:22:34 EST
Created attachment 483425 [details]
lspci -vvv from F15 Alpha

It seems that F15 Alpha comes with aspm disabled by default.
Comment 28 Chuck Ebbert 2011-03-10 13:31:17 EST
(In reply to comment #27)
> Created attachment 483425 [details]
> lspci -vvv from F15 Alpha
> 
> It seems that F15 Alpha comes with aspm disabled by default.

No, we are just a lot better about disabling ASPM when it doesn't work.
Comment 29 Reartes Guillermo 2011-05-08 17:04:51 EDT
In F15, i experienced the issue just only once, so it not gone but it is very difficult to trigger (i could not reproduce it). In addition, it was with an 'rc' kernel.
Comment 30 Bug Zapper 2011-06-01 10:45:50 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 31 Reartes Guillermo 2011-06-02 09:26:53 EDT
With F15, now released, i had no further problems with it (at least in the form of what is reported here) on the same motherboard & disks.

Keep in mind that i experienced it on F14 when i tested it. I do not have
any F14 installed instances so i cannot test it. The bug should probably changed to F14, just in case somebody is interested and closed only when F14 go EOL.

Thanks in advance.

Note You need to log in before you can comment on or make changes to this bug.