From john@monolith.rh.rit.edu  Tue May  2 08:17:27 2000
Return-Path: <john@monolith.rh.rit.edu>
Received: from monolith.rh.rit.edu (d142-l048.rh.rit.edu [129.21.142.48])
	by hub.freebsd.org (Postfix) with SMTP id 48CE037B8AC
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  2 May 2000 08:17:04 -0700 (PDT)
	(envelope-from john@monolith.rh.rit.edu)
Received: (qmail 38433 invoked by uid 1000); 2 May 2000 15:22:41 -0000
Message-Id: <20000502152241.38432.qmail@monolith.rh.rit.edu>
Date: 2 May 2000 15:22:41 -0000
From: jjm7570@cs.rit.edu
Sender: john@monolith.rh.rit.edu
Reply-To: jjm7570@cs.rit.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: sbc / pcm not fully recognizing AWE64
X-Send-Pr-Version: 3.2

>Number:         18345
>Category:       kern
>Synopsis:       [sound] sbc / pcm not fully recognizing AWE64
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-multimedia
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May  2 08:20:01 PDT 2000
>Closed-Date:    Sun Sep 11 11:41:43 GMT 2005
>Last-Modified:  Sun Sep 11 11:41:43 GMT 2005
>Originator:     John Mikucki
>Release:        FreeBSD 4.0-STABLE i386
>Organization:
>Environment:

  SMP dual PII-266, SuperMicro P6DKF motherboard.  AWE64 worked fine
under 3.4, but no longer recognizes things like the game port, the PCM
(wave) audio output, mixer, etc.  See dmesg for full hardware details.

  dmesg:  
  
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California. All rights reserved.
FreeBSD 4.0-STABLE #9: Sat Apr 29 01:42:36 EDT 2000
    root@monolith.rh.rit.edu:/usr/src/sys/compile/Obelisk
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x633  Stepping = 3
  Features=0x80fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX>
real memory  = 201326592 (196608K bytes)
avail memory = 192782336 (188264K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
IOAPIC #0 intpin 20 -> irq 15
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee00000
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee00000
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec00000
VESA: v1.2, 4096k memory, flags:0x0, mode table:0xc00c4bc8 (c0004bc8)
VESA: Number Nine Visual Technology Corporation
Pentium Pro MTRR support enabled
npx0: <math processor> on motherboard
npx0: flags 0x1 npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
isab0: <Intel 82371SB PCI to ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
pci0: <Intel PIIX3 ATA controller> at 7.1
pci0: <3Dfx Voodoo 2 graphics accelerator> at 17.0
xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xef00-0xef3f irq 17 at device 18.0 on pci0
xl0: Ethernet address: 00:60:08:0d:63:04
miibus0: <MII bus> on xl0
nsphy0: <DP83840 10/100 media interface> on miibus0
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci0: <S3 ViRGE VX graphics accelerator> at 19.0 irq 17
ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xec00-0xecff mem 0xfebff000-0xfebfffff irq 19 at device 20.0 on pci0
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
isa0: too many dependant configs (8)
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sbc0: <Creative SB AWE64> at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
sbc0: setting card to irq 5, drq 1, 5
pcm0: <SB DSP 4.16> on sbc0
unknown0: <Game> at port 0x200-0x207 on isa0
unknown1: <WaveTable> at port 0x620-0x623 on isa0
unknown2: <IDE> at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: Broken MP table detected: 8254 is not connected to IOAPIC #0 intpin 2
APIC_IO: routing 8254 via 8259 and IOAPIC #0 intpin 0
IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default
DUMMYNET initialized (000106)
IP Filter: initialized.  Default = pass all, Logging = enabled
IP Filter: v3.3.8
Waiting 5 seconds for SCSI devices to settle
SMP: AP CPU #1 Launched!




config file:

machine		"i386"
cpu		"I686_CPU"
ident		"Granite"
maxusers	62

options		INET			#InterNETworking

options		FFS			#Berkeley Fast Filesystem
options		NFS			#Network Filesystem
options		MSDOSFS			#MSDOS Filesystem
options		"CD9660"		#ISO 9660 Filesystem
options		PROCFS			#Process filesystem
options		"COMPAT_43"		#Compatible with BSD 4.3 [KEEP THIS!]
options		SCSI_DELAY=5000		#Be pessimistic about Joe SCSI device
options		UCONSOLE		#Allow users to grab the console
options		USERCONFIG		#boot -c editor
options		VISUAL_USERCONFIG	#visual boot -c editor

options		SYSVSHM
options 	SYSVMSG
options		SYSVSEM

options 	_KPOSIX_PRIORITY_SCHEDULING
options		ICMP_BANDLIM		#Rate limit bad replies

#####################################################################
# SMP OPTIONS:
#
# SMP enables building of a Symmetric MultiProcessor Kernel.
# NCPU sets the number of CPUs, defaults to 2.
# NBUS sets the number of busses, defaults to 4.
# NAPIC sets the number of IO APICs on the motherboard, defaults to 1.
# NINTR sets the total number of INTs provided by the motherboard.

# Mandatory:
options 	SMP			# Symmetric MultiProcessor Kernel
options 	APIC_IO			# Symmetric (APIC) I/O

options 	ROOTDEVNAME=\"da1s1a\"


device	isa
device	eisa
device	pci
device pnp0

device	fdc0	at isa? port IO_FD1 irq 6 drq 2
device	fd0	at fdc0 drive 0

# A single entry for any of these devices (ncr, ahb, ahc, amd) is
# sufficient for any number of installed devices.

device	ahc
device	scbus
device		da
device		cd	#Only need one of these, the code dynamically grows

# syscons is the default console driver, resembling an SCO console
 
device          atkbdc0 at isa? port IO_KBD
device          atkbd0  at atkbdc? irq 1 

#options	        "VM86"
options         "VESA"
device          vga0    at isa? 
device          sc0     at isa? 

#  The `bpfilter' pseudo-device enables the Berkeley Packet Filter.  Be
# events for resetting the demand dial activity timer - requires bpfilter.
#pseudo-device   bpfilter 4              #Berkeley packet filter
#options         PPP_FILTER              #enable bpf filtering (needs bpfilter)
#options         PPP_BSDCOMP
#device          ppp 2

# Mandatory, don't remove
device		npx0	at isa? port "IO_NPX" flags 0x1 irq 13 

# Laptop support (see LINT for more options)
device		apm0    at isa?	disable	# Advanced Power Management

device		sio0	at isa? port IO_COM1  irq 4 
device		sio1	at isa? port IO_COM2  irq 3
device		sio2	at isa? disable port IO_COM3 irq 5 
device		sio3	at isa? disable port IO_COM4 irq 9

device ppbus0
device		lpt0	at ppbus?

########################################################################
#SOUND STUFF::TESTING!
#device pcm0 at isa? port ? tty irq 5 drq 1 flags 0x5 vector pcmintr
device pcm
#device pca0 at isa? port IO_TIMER1
#device pcm0 at isa? port ? irq 5 drq 1 flags 0x5
device sbc
#######################################################################
device xl
device		miibus		# MII bus support

pseudo-device	loop
pseudo-device	ether
pseudo-device	vn	1
pseudo-device	pty	16
pseudo-device	gzip		# Exec gzipped a.out's

# KTRACE enables the system-call tracing facility ktrace(2).
# This adds 4 KB bloat to your kernel, and slightly increases
# the costs of each syscall.
options		KTRACE		#kernel tracing



options 	TCP_COMPAT_42		#emulate 4.2BSD TCP bugs
options 	IPFIREWALL		#firewall
options 	IPFIREWALL_VERBOSE	#print information about
					# dropped packets
options 	IPFIREWALL_FORWARD	#enable transparent proxy support
options 	IPFIREWALL_VERBOSE_LIMIT=100	#limit verbosity
#options 	IPV6FIREWALL		#firewall for IPv6
#options 	IPV6FIREWALL_VERBOSE
#options 	IPV6FIREWALL_VERBOSE_LIMIT=100
#options 	IPV6FIREWALL_DEFAULT_TO_ACCEPT
options 	IPDIVERT		#divert sockets
options 	IPFILTER		#ipfilter support
options 	IPFILTER_LOG		#ipfilter logging
#options 	IPSTEALTH		#support for stealth forwarding
#options 	TCPDEBUG

# The following options add sysctl variables for controlling how certain
# TCP packets are handled.
#
# TCP_DROP_SYNFIN adds support for ignoring TCP packets with SYN+FIN. This
# prevents nmap et al. from identifying the TCP/IP stack, but breaks support
# for RFC1644 extensions and is not recommended for web servers.
#
# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets.
# This is useful on systems which are exposed to SYN floods (e.g. IRC servers)
# or any system which one does not want to be easily portscannable.
#
options 	TCP_DROP_SYNFIN		#drop TCP packets with SYN+FIN
options 	TCP_RESTRICT_RST	#restrict emission of TCP RST

# ICMP_BANDLIM enables icmp error response bandwidth limiting.   You
# typically want this option as it will help protect the machine from
# D.O.S. packet attacks.
#
options 	ICMP_BANDLIM

# DUMMYNET enables the "dummynet" bandwidth limiter. You need
# IPFIREWALL as well. See the dummynet(4) manpage for more info.
# BRIDGE enables bridging between ethernet cards -- see bridge(4).
# You can use IPFIREWALL and dummynet together with bridging.
options 	DUMMYNET

#####################################################################
# POSIX P1003.1B

# Real time extensions added in the 1993 Posix
# P1003_1B: Infrastructure
# _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING
# _KPOSIX_VERSION:             Version kernel is built for

options 	P1003_1B
options 	_KPOSIX_PRIORITY_SCHEDULING
options 	_KPOSIX_VERSION=199309L


#####################################################################


>Description:

pnpinfo describes the card and its components as present, and the card
is detected (as indicated in the dmesg output above) but key
components on the card (grep for 'unknown' in dmesg output.) are not
found.  Attempts to, for example, use the mixer or wave devices fail.

Hopefully I simply need to add something to the config file, but it's
not at all clear what else to add.  See config file ~line 90 for sound
config statements.

>How-To-Repeat:
  
Compile kernel with included config file and boot system.
  
>Fix:
  
  None known.







>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->cg 
Responsible-Changed-By: johan 
Responsible-Changed-When: Thu Aug 24 04:56:44 PDT 2000 
Responsible-Changed-Why:  
Over to pcm maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=18345 

From: "Cameron Grant" <gandalf@vilnya.demon.co.uk>
To: <freebsd-gnats-submit@FreeBSD.org>, <jjm7570@cs.rit.edu>
Cc:  
Subject: Re: kern/18345: sbc / pcm not fully recognizing AWE64
Date: Tue, 27 Mar 2001 07:06:00 +0100

 unknown0: <Game> at port 0x200-0x207 on isa0
 unknown1: <WaveTable> at port 0x620-0x623 on isa0
 unknown2: <IDE> at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0
 
 these devices are not required for pcm.
 
 if pcm does not function, there is some other reason.
 
     -cg
 
 

From: "Jukka A. Ukkonen" <Jukka.Ukkonen@mawit.com>
To: freebsd-gnats-submit@FreeBSD.org, jjm7570@cs.rit.edu
Cc:  
Subject: Re: kern/18345: sbc / pcm not fully recognizing AWE64
Date: Fri, 28 Nov 2003 12:53:34 +0200

 	Hello everybody,
 
 	This could be a generic PnP problem, not a pcm/sbc problem only.
 
 	I am now hit by a related/similar problem in 4.9-STABLE.
 	The difference is though that in my case the kernel does not
 	recognize even the actual pcm/sbc audio (logical) device.
 
 	This became kind of long because I am quoting quite a lot of
 	the kernel messages from a verbose boot.
 	So, what happens in my environment at boot time goes like...
 
 aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/253 SCBs
 pcm0: <AudioPCI ES1373-B> port 0xef00-0xef3f irq 9 at device 12.0 on pci0
 pcm0: <TriTech TR28023 AC97 Codec (id = 0x54524103)>
 pcm0: Codec features 6 bit master volume, no 3D Stereo Enhancement
          using shared irq9.
 pcm0: sndbuf_setmap 1f138000, 1000; 0xc2204000 -> 1f138000
 pcm0: sndbuf_setmap 1f0fa000, 1000; 0xc2206000 -> 1f0fa000
 fxp0: <Intel 82559 Pro/100 Ethernet> port 0xee80-0xeebf mem 0xff900000-0xff9ffff
 f,0xffafd000-0xffafdfff irq 2 at device 13.0 on pci0
 fxp0: using memory space register mapping
          using shared irq2.
 fxp0: Ethernet address 00:e0:81:10:36:f0
 fxp0: PCI IDs: 8086 1229 8086 000c 0008
 fxp0: Dynamic Standby mode is disabled
 
 	So, another Ensonic sound device integrated in the mother board
 	is found OK, and the story continues...
 
 pcib1: <Intel 82443GX host to AGP bridge> on motherboard
 pci2: <PCI bus> on pcib1
 ex_isa_identify()
 ata-: ata0 exists, using next available unit number
 ata-: ata1 exists, using next available unit number
 Trying Read_Port at 203
 Trying Read_Port at 243
 CTL0042: start dependant
 CTL0042: adding irq mask 0x20
 CTL0042: adding dma mask 0x2
 CTL0042: adding dma mask 0x20
 CTL0042: adding io range 0x220-0x22f, size=0x10, align=0x1
 CTL0042: adding io range 0x330-0x331, size=0x2, align=0x1
 CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1
 CTL0042: start dependant
 CTL0042: adding irq mask 0x6a0
 CTL0042: adding dma mask 0xb
 CTL0042: adding dma mask 0xe0
 CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
 CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
 CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1
 CTL0042: start dependant
 CTL0042: adding irq mask 0x6a0
 CTL0042: adding dma mask 0xb
 CTL0042: adding dma mask 0xe0
 CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
 CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
 CTL0042: start dependant
 CTL0042: adding irq mask 0x6a0
 CTL0042: adding dma mask 0xb
 CTL0042: adding dma mask 0xe0
 CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
 CTL0042: start dependant
 CTL0042: adding irq mask 0x6a0
 CTL0042: adding dma mask 0xb
 CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
 CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
 CTL0042: adding io range 0x388-0x38b, size=0x4, align=0x1
 CTL0042: start dependant
 CTL0042: adding irq mask 0x6a0
 CTL0042: adding dma mask 0xb
 CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
 CTL0042: adding io range 0x300-0x331, size=0x2, align=0x30
 CTL0042: start dependant
 CTL0042: adding irq mask 0x6a0
 CTL0042: adding dma mask 0xb
 CTL0042: adding io range 0x220-0x28f, size=0x10, align=0x20
 CTL0042: start dependant
 isa0: too many dependant configs (8)
 CTL7002: start dependant
 CTL7002: adding io range 0x200-0x207, size=0x8, align=0x1
 CTL7002: start dependant
 CTL7002: adding io range 0x200-0x20f, size=0x8, align=0x8
 CTL7002: end dependant
 CTL0022: start dependant
 CTL0022: adding io range 0x620-0x623, size=0x4, align=0x1
 CTL0022: start dependant
 CTL0022: adding io range 0x620-0x683, size=0x4, align=0x20
 CTL0022: end dependant
 CTL2011: start dependant
 CTL2011: adding irq mask 0x400
 CTL2011: adding io range 0x168-0x16f, size=0x8, align=0x1
 CTL2011: adding io range 0x36e-0x36f, size=0x2, align=0x1
 CTL2011: start dependant
 CTL2011: adding irq mask 0x800
 CTL2011: adding io range 0x1e8-0x1ef, size=0x8, align=0x1
 CTL2011: adding io range 0x3ee-0x3ef, size=0x2, align=0x1
 CTL2011: start dependant
 CTL2011: adding irq mask 0x9c00
 CTL2011: adding io range 0x180-0x1bf, size=0x8, align=0x8
 CTL2011: adding io range 0x306-0x33f, size=0x2, align=0x8
 CTL2011: start dependant
 CTL2011: adding irq mask 0x8000
 CTL2011: adding io range 0x170-0x177, size=0x8, align=0x1
 CTL2011: adding io range 0x376-0x376, size=0x1, align=0x1
 CTL2011: end dependant
 isa_probe_children: disabling PnP devices
 isa_probe_children: probing non-PnP devices
 orm0: <Option ROMs> at iomem 0xc0000-0xccfff,0xd0000-0xd57ff on isa0
 pmtimer0 on isa0
 
 	So, this is definitely the SB-AWE64 talking here
 	CTL0042 being the audio device, CTL7002 being the
 	joystick / game port, CTL0022 the wave table, and
 	CTL2011 the IDE interface.
 
 	Notice that now the PnP devices become disabled for
 	non-PnP probes to take place. Everything goes just
 	fine until...
 
 isa_probe_children: probing PnP devices
 unknown: <Audio> can't assign resources
 unknown: <Audio> at port 0x220-0x22f irq 10 on isa0
 joy1: <Generic PnP Joystick> at port 0x208-0x20f on isa0
 adv1: Invalid baseport of 0x620 specified. Nearest valid baseport is 0x330.  Fai
 ling probe.
 pcf1: can't reserve irq, polled mode.
 pcf1: <PCF8584 I2C bus controller> at port 0x620-0x62f on isa0
 
 	So, when the PnP devices should be probed for real the AWE64
 	board is not recognized. The piggy-back joystick interface on
 	the same card is found OK, but the wave table and IDE interfaces
 	are not seen at all.
 	It sort of looks like the PnP boards should be explicitly
 	enabled again before any further PnP probes are properly
 	replied. If that is the case the SB-AWE64 problems are
 	actually problems in how the PnP probes are done.
 
 	When the system is up and running the "pnpinfo" program
 	finds all of the logical devices without a flaw.
 	In case someone wonders the devices pcm and sbc have been
 	compiled static in the kernel.
 
 	The almost comical thing about this is that with older
 	3.5.1 kernels there is no problem in finding the SB audio
 	device.
 
 	I hope this helps.
 
 		// jau
 
 

From: "Jukka A. Ukkonen" <ext-jukka.ukkonen@nokia.com>
To: freebsd-gnats-submit@FreeBSD.org, jjm7570@cs.rit.edu
Cc:  
Subject: Re: kern/18345: sbc / pcm not fully recognizing AWE64
Date: Mon, 03 May 2004 17:19:33 +0300

 This could be the same problem as in 
 
 
 kern/51308 <http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/51308>
 
 
 	// jau
 
 

From: "Jukka A. Ukkonen" <Jukka.Ukkonen@mawit.com>
To: freebsd-gnats-submit@FreeBSD.org, jjm7570@cs.rit.edu,
	core@freebsd.org
Cc:  
Subject: Re: kern/18345: sbc / pcm not fully recognizing AWE64
Date: Thu, 06 May 2004 23:03:53 +0300

 	Right, I am still ranting on about SB-AWE-64 probe problem...
 	This time I even have the answer. ;-)
 
 	It seems my hypothesis about the PnP mechanism itself being broken
 	in 4.x was entirely correct. When I simply disabled the part of
 	isa_common.c which generates the note...
 
 		isa_probe_children: disabling PnP devices
 
 	and disables the PnP devices my "broken" SB-AWE-64-ISA card was
 	probed successfully and started working just fine again immediately
 	after the next boot. (The "SoundBlaster 16" type shown below is
 	obviously an echo of a mistaken device ID code or simply due to
 	shared sb16/sbc module, but since the cards are largely the same
 	this does not really matter.)
 
 sbc0: <SoundBlaster 16> at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0
 sbc0: setting card to irq 5, drq 1, 5
 pcm1: <SB16 DSP 4.16> on sbc0
 pcm1: sndbuf_setmap 48000, 1000; 0xd9f6f000 -> 48000
 pcm1: sndbuf_setmap 49000, 1000; 0xd9f70000 -> 49000
 pca0 at port 0x40 on isa0
 joy0 at port 0x201 on isa0
 
 
 	Let me put it this way. I am not happy - not because the fully
 	operational sound card were some sort of disappointment to me,
 	but because the bug has been such an obvious one and it has been
 	lingering on through several minor releases though there have
 	been complaints hinting to the roots of the problem.
 
 	What actually happens is that some Sound Blaster cards really
 	are obedient little cards, and after being told to remain quiet
 	they really do exactly that. They refuse to talk actively even
 	if requested to assign an IRQ.
 	When the kernel after probing for the legacy ISA devices starts
 	telling the PnP devices the communication settings they should
 	use these cards simply remain quiet. They start reacting again
 	when pnpinfo is used to probe for them, but the autoconfigure
 	phase is already over and done with then.
 
 	Even though majority of PnP devices maybe interpret silence being
 	over when the kernel starts to assign communication settings all
 	devices are not alike. The ones that still refuse to do any active
 	communication may well be in error in doing so, but they at least
 	err on the safe side. Stubbornly sticking to the idea that the
 	current PnP logic is the "proper" way to do it simply makes some
 	otherwise perfectly good devices unusable.
 	In fact it does not even matter which ones are in error, those
 	that keep silent or those that do not. The old golden rule should
 	still be followed: "Be pedantic about what you make others accept
 	from you, and liberal about what you are willing to accept from
 	others." The Sound Blaster cards definitely being the others here.
 	Sound Blaster cards can hardly be changed, but the PnP logic
 	can. And supposedly some SB cards are not the only PnP devices
 	that interpret being disabled this way.
 
 	So, this is a generic PnP problem. I do not wish to propose
 	any particular way to solve this. There are alternatives of
 	course, but it should be the PnP code administrators to decide
 	as long as they do not stick to the current method.
 
 	1) One could simply drop the disabling phase completely and
 	check all legacy ISA communication settings against the PnP
 	settings catalog and marking any overlapping configurations
 	void/unusable before the PnP devices communication settings
 	are assigned.
 
 	2) One could leave the disabling as is and resolve to resetting
 	and reprobing the PnP devices after and the legacy ISA devices
 	have been configured.
 
 	3) Find some other logic to avoid devices being left disabled.
 
 	I really, really hope this helps - and preferably quickly.
 
 
 		// jau
 
 

From: "M. Warner Losh" <imp@bsdimp.com>
To: Jukka.Ukkonen@mawit.com
Cc: freebsd-gnats-submit@freebsd.org, jjm7570@cs.rit.edu,
	core@freebsd.org
Subject: Re: kern/18345: sbc / pcm not fully recognizing AWE64
Date: Thu, 06 May 2004 19:13:53 -0600 (MDT)

 In message: <409A9A29.7020502@mawit.com>
             "Jukka A. Ukkonen" <Jukka.Ukkonen@mawit.com> writes:
 : 
 : 	Right, I am still ranting on about SB-AWE-64 probe problem...
 : 	This time I even have the answer. ;-)
 : 
 : 	It seems my hypothesis about the PnP mechanism itself being broken
 : 	in 4.x was entirely correct. When I simply disabled the part of
 : 	isa_common.c which generates the note...
 : 
 : 		isa_probe_children: disabling PnP devices
 : 
 : 	and disables the PnP devices my "broken" SB-AWE-64-ISA card was
 : 	probed successfully and started working just fine again immediately
 : 	after the next boot. (The "SoundBlaster 16" type shown below is
 : 	obviously an echo of a mistaken device ID code or simply due to
 : 	shared sb16/sbc module, but since the cards are largely the same
 : 	this does not really matter.)
 : 
 : sbc0: <SoundBlaster 16> at port 0x220-0x22f irq 5 drq 1 flags 0x15 on isa0
 : sbc0: setting card to irq 5, drq 1, 5
 : pcm1: <SB16 DSP 4.16> on sbc0
 : pcm1: sndbuf_setmap 48000, 1000; 0xd9f6f000 -> 48000
 : pcm1: sndbuf_setmap 49000, 1000; 0xd9f70000 -> 49000
 : pca0 at port 0x40 on isa0
 : joy0 at port 0x201 on isa0
 : 
 : 
 : 	Let me put it this way. I am not happy - not because the fully
 : 	operational sound card were some sort of disappointment to me,
 : 	but because the bug has been such an obvious one and it has been
 : 	lingering on through several minor releases though there have
 : 	been complaints hinting to the roots of the problem.
 
 Generally speaking, exposing a whiny attitude generally isn't
 conducive to accomplishing your goals of getting this fixed.  Human
 nature being what it is and all that.  However, having said that, I'm
 reading past your attitude to try to resolve the problem.
 
 : 	What actually happens is that some Sound Blaster cards really
 : 	are obedient little cards, and after being told to remain quiet
 : 	they really do exactly that. They refuse to talk actively even
 : 	if requested to assign an IRQ.
 : 	When the kernel after probing for the legacy ISA devices starts
 : 	telling the PnP devices the communication settings they should
 : 	use these cards simply remain quiet. They start reacting again
 : 	when pnpinfo is used to probe for them, but the autoconfigure
 : 	phase is already over and done with then.
 
 What does this refusal look like?  What port reads doesn't it reply
 to?  It seems odd that pnpinfo would work and the kernel probe
 wouldn't.
 
 : 	Even though majority of PnP devices maybe interpret silence being
 : 	over when the kernel starts to assign communication settings all
 : 	devices are not alike. The ones that still refuse to do any active
 : 	communication may well be in error in doing so, but they at least
 : 	err on the safe side. Stubbornly sticking to the idea that the
 : 	current PnP logic is the "proper" way to do it simply makes some
 : 	otherwise perfectly good devices unusable.
 : 	In fact it does not even matter which ones are in error, those
 : 	that keep silent or those that do not. The old golden rule should
 : 	still be followed: "Be pedantic about what you make others accept
 : 	from you, and liberal about what you are willing to accept from
 : 	others." The Sound Blaster cards definitely being the others here.
 : 	Sound Blaster cards can hardly be changed, but the PnP logic
 : 	can. And supposedly some SB cards are not the only PnP devices
 : 	that interpret being disabled this way.
 
 Where do you get this information.  It is news to me.
 
 : 	So, this is a generic PnP problem. I do not wish to propose
 : 	any particular way to solve this. There are alternatives of
 : 	course, but it should be the PnP code administrators to decide
 : 	as long as they do not stick to the current method.
 
 My PNP cards work just fine.  I'm surprised that you are having
 problems.  I'm upgrading to 4.10 RC tonight and will try the few PnP
 ISA cards I have.
 
 : 	1) One could simply drop the disabling phase completely and
 : 	check all legacy ISA communication settings against the PnP
 : 	settings catalog and marking any overlapping configurations
 : 	void/unusable before the PnP devices communication settings
 : 	are assigned.
 
 Can't do that.  It violates the spec.  Also, what's the PnP catalog
 here?  Is it the list you get from the BIOS or is it pnp cards.  if it
 is the pnp cards, then you MUST disable them so you can enumerate
 them.  There's no way around that.  that's how pnp Isa cards work.
 
 : 	2) One could leave the disabling as is and resolve to resetting
 : 	and reprobing the PnP devices after and the legacy ISA devices
 : 	have been configured.
 
 Can't do that either.
 
 : 	3) Find some other logic to avoid devices being left disabled.
 
 That's not likely a viable option either.
 
 Maybe you could offer a suggested patch?
 
 Warner
Responsible-Changed-From-To: cg->sound 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Thu Sep 9 19:30:14 GMT 2004 
Responsible-Changed-Why:  
With permission, reassign to mailing list alias. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=18345 
State-Changed-From-To: open->closed 
State-Changed-By: netchild 
State-Changed-When: Sun Sep 11 11:40:09 GMT 2005 
State-Changed-Why:  
Too much changes in 5.x. Please open a new PR with 5.x debugging info 
("pciconf -v -l", ...) in case you still can reproduce it there. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=18345 
>Unformatted:
