I have JMicron 363 PCIE to SATA/PATA controller. It is rather common and cheap device. The problem: two IDE drives attached to JMicron give interrupt lost at any substential write activity. ------------------ May 27 11:24:34 comp90 kernel: [ 9027.239263] ata11: lost interrupt (Status 0x58) May 27 11:24:34 comp90 kernel: [ 9027.240535] ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen May 27 11:24:34 comp90 kernel: [ 9027.241801] ata11.00: failed command: WRITE DMA EXT May 27 11:24:34 comp90 kernel: [ 9027.243040] ata11.00: cmd 35/00:18:07:02:b0/00:03:13:00:00/e0 tag 0 dma 405504 out May 27 11:24:34 comp90 kernel: [ 9027.243041] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) May 27 11:24:34 comp90 kernel: [ 9027.245300] ata11.00: status: { DRDY } May 27 11:24:34 comp90 kernel: [ 9027.246397] ata11: soft resetting link May 27 11:24:35 comp90 kernel: [ 9027.830685] ata11.00: configured for UDMA/100 May 27 11:24:35 comp90 kernel: [ 9027.871394] ata11.01: configured for UDMA/100 May 27 11:24:35 comp90 kernel: [ 9027.872493] ata11.00: device reported invalid CHS sector 0 May 27 11:24:35 comp90 kernel: [ 9027.873635] ata11: EH complete ----------- after a number of such errors, the kernel configure jmicron at UDMA/33 Then Jmicron 363 becomes much more stable, and give sumilar errors much less frequently. ---------------- May 28 01:32:53 comp90 kernel: [59876.584505] ata11: lost interrupt (Status 0x58 ) May 28 01:32:53 comp90 kernel: [59876.586511] ata11.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen May 28 01:32:53 comp90 kernel: [59876.588473] ata11.00: failed command: WRITE DM A EXT May 28 01:32:53 comp90 kernel: [59876.590466] ata11.00: cmd 35/00:00:4f:14:94/00 :04:30:00:00/e0 tag 0 dma 524288 out May 28 01:32:53 comp90 kernel: [59876.590467] res 40/00:00:00:4f:c2/00: 00:00:00:00/00 Emask 0x4 (timeout) May 28 01:32:53 comp90 kernel: [59876.594408] ata11.00: status: { DRDY } May 28 01:32:53 comp90 kernel: [59876.596411] ata11: soft resetting link May 28 01:32:54 comp90 kernel: [59877.349661] ata11.00: configured for UDMA/33 May 28 01:32:54 comp90 kernel: [59877.493227] ata11.01: configured for UDMA/33 May 28 01:32:54 comp90 kernel: [59877.494888] ata11.00: device reported invalid CHS sector 0 --------------- jmicron bios was upgrated to the latest 1.07.24 ftp://driver.jmicron.com.tw/SATA_Controller/Option_ROM/ same thing. Looks like jmicron 363 is broken even at UDMA/33 and should be UDMA blacklisted. -------------- lspci -vv info ---------------- 03:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03) (prog-if 01 [AHCI 1.0]) Subsystem: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 5: Memory at f7e10000 (32-bit, non-prefetchable) [size=8K] Expansion ROM at f7e00000 [disabled] [size=64K] Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] Express (v1) Legacy Endpoint, MSI 01 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <1us, L1 <16us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Kernel driver in use: ahci 03:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03) (prog-if 85 [Master SecO PriO]) Subsystem: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin B routed to IRQ 17 Region 0: I/O ports at e040 [size=8] Region 1: I/O ports at e030 [size=4] Region 2: I/O ports at e020 [size=8] Region 3: I/O ports at e010 [size=4] Region 4: I/O ports at e000 [size=16] Capabilities: [68] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: pata_jmicron
do it happen with previous fedora versions or with another kernel (systemrescuecd)? I think i have one of those (i will check that later), but i never attache an IDE device, i just used SATA drives.
1. I did not try this device with older Fedora versions. 2. I did not notice a problem with SATA. Initially IDE problem was also not noticed, it popped up during massive disk write activity to IDE. Disk read is much less problematic. Also, as it was mentioned above the problem happens much less frequent on UDMA/33 than on UDMA/100
The two JMB362 controllers i have are actually onboard and sata only, the pci one was a promise one. So i do not have the same card. JMicron Technology Corp. JMB362 AHCI Controller [197b:2362] (rev 10) can you upload a dmesg and some pci info? # lspci -nnvv # lspci -k # lspci -tvn and some information about the hardware? # cat /sys/devices/virtual/dmi/id/product_name # cat /sys/devices/virtual/dmi/id/bios_version # cat /sys/devices/virtual/dmi/id/board_name Cheers.
Created attachment 605272 [details] lspci -nvv
Created attachment 605273 [details] lspci -k
Created attachment 605274 [details] lspci -tnv
cat /sys/devices/virtual/dmi/id/product_name System Product Name cat /sys/devices/virtual/dmi/id/bios_version 1303 cat /sys/devices/virtual/dmi/id/board_name P8Z77-M PRO
On Asus, the P8Z77-M PRO latest bios is 1504 You might want to check that first. If that does not fix it then please upload a dmesg, right after power-on # dmesg > dmesg-poweron.out
In addition a dmesg right after booting, please upload also the output of: # cat /proc/interrupts Also please note that for the provided 'lspci -nvv' (comment #4) you must use root user, otherwise you get these 'Capabilities: <access denied>' messages.
Created attachment 605952 [details] interrupts
Created attachment 605953 [details] lspci -nvv as root
Right now I can not get dmesg after reboot, because the computer cannot be rebooted right now. I probably can reboot it after Aug 29.
Pelase provide also a: # cat /proc/cpuinfo
Created attachment 605964 [details] cpuinfo
Created attachment 608273 [details] dmesg
Created attachment 611259 [details] dmesg
Is this still happening with 3.8.2 in updates-testing?
The JMicron 363 is still inside of the computer, but I do not use because it was and probably still is unreliable.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.