NetBSD Problem Report #45917

From mm_lists@pulsar-zone.net  Fri Feb  3 02:41:25 2012
Return-Path: <mm_lists@pulsar-zone.net>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 9FB8363D5E6
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  3 Feb 2012 02:41:25 +0000 (UTC)
Message-Id: <201202030241.q132fMUC012906@ginseng.pulsar-zone.net>
Date: Thu, 2 Feb 2012 21:41:22 -0500
From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@gnats.NetBSD.org
Subject: Unsupported VT6415 PCIE IDE single-channel controller

>Number:         45917
>Category:       kern
>Synopsis:       Unsupported VT6415 PCIE IDE single-channel controller
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    andvar
>State:          closed
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 03 02:45:00 +0000 2012
>Closed-Date:    Fri May 09 20:13:27 +0000 2025
>Last-Modified:  Fri May 09 20:13:27 +0000 2025
>Originator:     Matthew Mondor
>Release:        NetBSD 5.1_STABLE and NetBSD 5.99.63
>Organization:
>Environment:
NetBSD ninja.xisop 5.1_STABLE NetBSD 5.1_STABLE (GENERIC) #0: Wed Feb  1 06:51:12 EST 2012  root@ninja.xisop:/usr/obj/sys/arch/amd64/compile/GENERIC amd64
Architecture: amd64
Machine: amd64
_
NetBSD 5.99.63 (GENERIC) #2: Thu Feb 2 05:57:31 EST 2012
Architecture: amd64
Machine: amd64

>Description:

Although it's possible to use the disks connected to that interface in
PIO mode, the system is extremely sluggish and unstable, with interrupt
storms, when accessing data on them.  I've tried to add the device and
make viaide.c attach like some of the other supported devices, but have
not succeeded so far.  Perhaps that interface is slightly different
than the others, or that to attach the unsupported PCIE device must
also be supported...

ppb1 at pci0 dev 28 function 0: vendor 0x8086 product 0x1c10 (rev. 0xb5)
ppb1: unsupported PCI Express version
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
ppb2 at pci0 dev 28 function 4: vendor 0x8086 product 0x1c18 (rev. 0xb5)
ppb2: unsupported PCI Express version
pci3 at ppb2 bus 3
pci3: i/o space, memory space enabled, rd/line, wr/inv ok
pciide0 at pci3 dev 0 function 0
pciide0: vendor 0x1106 product 0x0415 (rev. 0x00)
pciide0: bus-master DMA support present, but unused (no driver support)
pciide0: primary channel wired to native-PCI mode
pciide0: using ioapic0 pin 16 for native-PCI interrupt
atabus0 at pciide0 channel 0
pciide0: secondary channel wired to native-PCI mode
atabus1 at pciide0 channel 1

>How-To-Repeat:

Use an Asus P8H67-M PRO motherboard which supports both SATA and PATA,
try to copy data from a PATA drive to the SATA one.  Notice the system
becomming unresponsive.

>Fix:

Some driver attachment stubs to add, more research needed to properly
do it.

>Release-Note:

>Audit-Trail:
From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/45917: Unsupported VT6415 PCIE IDE single-channel
 controller
Date: Tue, 21 Feb 2012 16:03:34 -0500

 On Fri,  3 Feb 2012 02:45:00 +0000 (UTC)
 Matthew Mondor <mm_lists@pulsar-zone.net> wrote:

 > ppb1 at pci0 dev 28 function 0: vendor 0x8086 product 0x1c10 (rev. 0xb5)
 > ppb1: unsupported PCI Express version
 > pci2 at ppb1 bus 2
 > pci2: i/o space, memory space enabled, rd/line, wr/inv ok
 > ppb2 at pci0 dev 28 function 4: vendor 0x8086 product 0x1c18 (rev. 0xb5)
 > ppb2: unsupported PCI Express version
 > pci3 at ppb2 bus 3
 > pci3: i/o space, memory space enabled, rd/line, wr/inv ok
 > pciide0 at pci3 dev 0 function 0
 > pciide0: vendor 0x1106 product 0x0415 (rev. 0x00)
 > pciide0: bus-master DMA support present, but unused (no driver support)
 > pciide0: primary channel wired to native-PCI mode
 > pciide0: using ioapic0 pin 16 for native-PCI interrupt
 > atabus0 at pciide0 channel 0
 > pciide0: secondary channel wired to native-PCI mode
 > atabus1 at pciide0 channel 1

 Another interesting consequence of using PIO was that as transfers were
 happenning (with at most 1.2MB/s transfer rates) a lot of CPU time
 would get accumulated on any active process, it seems.  Of course,
 during such transfers the system was also much less responsive.

 For now I could fortunately enable DMA by forcing the 0x0001 flag to
 pciide(4), and transfers are much more stable and efficient using the
 PATA interface.  The SATA interfaces work well.  Of course, ideally
 viaide(4) should be fixed, but at least I have a working system.

 There is a new issue that I discovered when using the disks with DMA
 this way.  For certain operations, such as using dd and cgd to scrub a
 drive (/dev/zero being fed through aes with a random key), performance
 was decent at first (12MB/sec) yet steadily decreasing down to about
 2MB/s at which point the whole system was less responsive.  If I
 suspended and resumed the dd process, the drive would write out its
 cache at full speed, and performance would be decent again at 12MB/sec
 to again drop gradually.  I used a script to stop/restart the process
 at regular interavals for the procedure to finally complete.  It's like
 if there was a cache related issue where general system performance
 drops as the cache is filling.  I have been wondering if this issue
 could in any way be related to the one I had with re(4) (kern/45928),
 but unlike when using re(4) the system was still usable.

 I have yet to do more testing with ACPI disabled soon.
 -- 
 Matt

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 12 Jul 2014 19:56:46 +0000
State-Changed-Why:
Does this work nowadays?


From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/45917 (Unsupported VT6415 PCIE IDE single-channel
 controller)
Date: Sat, 12 Jul 2014 22:46:46 -0400

 On Sat, 12 Jul 2014 19:56:47 +0000 (UTC)
 dholland@NetBSD.org wrote:

 > Does this work nowadays?

 On netbsd-6:

 pciide0 at pci3 dev 0 function 0: vendor 0x1106 product 0x0415 (rev. 0x00)
 pciide0: bus-master DMA support present, used without full driver support

 I forced DMA with flags in the kernel config, which works fine; but no
 "full driver support" yet, so without the flags DMA would not be enabled
 by default.

 pciide* at pci? dev ? function ? flags 0x0001   # GENERIC pciide driver

 I have not tested again on -current, which I seldom use and would have
 to update.  I guess that I could also parse the source changes and see
 if it's worth trying.  I'll try to report soon about that.

 Thanks,
 -- 
 Matt

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/45917 (Unsupported VT6415 PCIE IDE single-channel
 controller)
Date: Sun, 13 Jul 2014 07:16:11 +0000

 On Sun, Jul 13, 2014 at 02:50:06AM +0000, Matthew Mondor wrote:
  >  pciide0 at pci3 dev 0 function 0: vendor 0x1106 product 0x0415 (rev. 0x00)
  >  pciide0: bus-master DMA support present, used without full driver support
  >  
  >  I forced DMA with flags in the kernel config, which works fine; but no
  >  "full driver support" yet, so without the flags DMA would not be enabled
  >  by default.
  >  
  >  pciide* at pci? dev ? function ? flags 0x0001   # GENERIC pciide driver
  >  
  >  I have not tested again on -current, which I seldom use and would have
  >  to update.  I guess that I could also parse the source changes and see
  >  if it's worth trying.  I'll try to report soon about that.

 It's probably not; I was thinking more about ACPI when I asked.
 There's still no entry in pcidevs for that, so unless you have a bios
 option to turn it into ahcisata it's probably not going to do any
 good.

 If it's a viaide(4) that we just don't know about, you might be able
 to get it to work by adding it to the match logic, but the value of
 the product ID makes me think that isn't too likely.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/45917 (Unsupported VT6415 PCIE IDE single-channel
 controller)
Date: Sun, 13 Jul 2014 07:44:50 +0000

 On Sun, Jul 13, 2014 at 07:20:00AM +0000, David Holland wrote:
  >  If it's a viaide(4) that we just don't know about, you might be able
  >  to get it to work by adding it to the match logic, but the value of
  >  the product ID makes me think that isn't too likely.

 Actually it might be, given that it's PATA and PCIe... digging around
 a bit suggests that it is; namely, it looks as if Linux handles it
 that way.

 So, there's a decent chance that if you add an entry to
 pciide_via_products[] in sys/dev/pci/viaide.c that it will match and
 work. That is probably worth a try.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 13 Jul 2014 07:45:55 +0000
State-Changed-Why:
feedback received


Responsible-Changed-From-To: kern-bug-people->andvar
Responsible-Changed-By: andvar@NetBSD.org
Responsible-Changed-When: Sun, 30 Mar 2025 19:33:46 +0000
Responsible-Changed-Why:
take, working on adding the support.

From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45917 CVS commit: src/sys/dev/pci
Date: Thu, 3 Apr 2025 15:35:54 +0000

 Module Name:	src
 Committed By:	andvar
 Date:		Thu Apr  3 15:35:54 UTC 2025

 Modified Files:
 	src/sys/dev/pci: pcidevs pciide_apollo_reg.h viaide.c

 Log Message:
 viaide(4): Add support for VIA VT6415/VT6330 single-channel IDE controllers.

 Beyond adding the usual identification code, several adjustments were required:

 1) Introduced 'single_channel` to set 'nchannels` to 1 for this controller.

 2) Added 'APO_IDECONF_ALWAYS_EN` definition and the 'no_ideconf` flag to mimic
    enabled channel bits, as this controller's enable chip register is unset.
    Applied the same to VT6410, following OpenBSD and Linux, since some
    controllers are known to not set this register as well.

 3) Combined all VIA controllers identified by PCI ID (not ISA bus) using switch
    fallthrough, as they currently share the same UDMA setting. Consequently,
    the VX900 name printing was moved to the device description and adjusted
    to better reflect the device.

 4) Moved setting interface bits for RAID controllers under the RAID capability
    check, enabling the above fallthrough and paving the way for support of other
    RAID-capable controllers in upcoming changes.

 5) The VT6330 is a combo FireWire/IDE controller. Added its FireWire controller
    PCI ID to pcidevs.

 Tested on ASRock P5B-DE.

 Reviewed by jak and bad.

 Addresses PR kern/45917


 To generate a diff of this commit:
 cvs rdiff -u -r1.1519 -r1.1520 src/sys/dev/pci/pcidevs
 cvs rdiff -u -r1.20 -r1.21 src/sys/dev/pci/pciide_apollo_reg.h
 cvs rdiff -u -r1.94 -r1.95 src/sys/dev/pci/viaide.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->needs-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Thu, 03 Apr 2025 21:12:13 +0000
State-Changed-Why:
support for the controller commited, moving to needs-pullups if it will be feasible.

State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Thu, 24 Apr 2025 16:20:37 +0000
State-Changed-Why:
pullups requested: [pullup-9 #1944] and [pullup-10 #1101]


State-Changed-From-To: pending-pullups->closed
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Fri, 09 May 2025 20:13:27 +0000
State-Changed-Why:
support added, pullups applied to netbsd-10 and netbsd-9. earlier version unsupported.

>Unformatted:
 To: gnats-bugs@gnats.NetBSD.org
 Subject: Unsupported VT6415 PCIE IDE single-channel controller
 From: mm_lists@pulsar-zone.net
 Reply-To: mm_lists@pulsar-zone.net
 X-send-pr-version: 3.95

Home	PR Database Search