[issue676] SB600 HDA audio (Realtek ALC883) glitch - IRQ sharing?

["Joe \"Floid\" Kanowitz" <sinknull@xxxxxxxxxxxxxxxxxxxxxxx>]

Joe "Floid" Kanowitz <jkanowitz@snet.net> added the comment:

No USB keyboard for me, though if there's any reason to get masochistic I have a
PS/2 to USB adapter in a KVM.

Tried usb01.patch , unfortunately problems remain.

I had the following on uhub0 for the first boot attempt:
 ugen0: CPS UPS AE485, rev 1.10/0.01, addr 2
 ums0: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), rev 1.10/3.00,
addr 3, iclass 3/1

I should've taken better notes -- the kernel either enumerated usb0 or uhub0
before locking up quietly, the block cursor on a new line and the keyboard
unresponsive.

For the second boot, I unplugged both devices and things went smoothly until the
EHCI driver loaded, with a page fault after enumerating its uhub5: 10 ports with
10 removable, self powered.

More debugging-by-photograph, this time with meat-based OCR:

Fatal trap 12: page fault while in kernel mode
mp_lock = 00000000; cpuid = 0; lapic.id = 00000000
fault virtual address   = 0x58
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xC048A873
stack pointer           = 0x10:0xDA3D3D58
frame pointer           = 0x10:0xDA3D3D64
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = Idle
current thread          = pri 44 (CRIT)

Stopped at  usb_discover+0x70:  movl  0x58(%eax),%edx

Backtrace:
usb_discover(c3d0a610,1f4,0,0,c062d600) at usb_discover+0x70
usb_event_thread(c3d0a610,0,0,0,0) at usb_event_thread+0x48
kthread_exit() at kthread_exit

. ..

Of course, I forgot to disable ehci in loader.conf and see if the sound bug
improved before reporting all this.

===[OFF_TOPIC_PADDING]

Unrelated to *this* bug, some miscellaneous information for the search engines
to pick up:

- Modular X.org ("1.2.0") doesn't like me, as evidenced by the server dying on
signal 11 and/or demonstrating a problem with WaitForSomething() essentially
identical to the one Jeremy C. Reed reported a year ago:

http://lists.freedesktop.org/archives/xorg/2006-March/013678.html
http://leaf.dragonflybsd.org/mailarchive/users/2006-03/msg00082.html

Since the new ati driver, and pretty much every 6.n.n version, doesn't seem to
have improved at autoconfiguration of DVI monitors (or, 9 times out of 10, at
working at all), and the most interesting information I could find had me
sending a note to AMD's Investor Relations that fglrx doesn't cover everyone.

- Every component of Gnome 2.18.1 from pkgsrc-current builds (hooray!) except
for gnome-user-doc.  The problem with that seems to be a Python type error, I
need to investigate.

- With BUILD_MAKE_FLAGS=-j 6 set, some of the Gnome packages outside gnome-base
do get into races that have gmake stop on a 'write error.'  The really lazy way
to approach this was just to restart the bmake every time where it left off.

- The Gnome System Monitor panel applet (2.18.0) shows a constant "IOWait"
utilization taking up 50% of the "Processor" -- it doesn't break it down by CPU.
 This even when top shows the system idle with <1% utilization in all categories.

===[END OFF_TOPIC_PADDING]

-Joe "Floid" Kanowitz

_____________________________________________________
DragonFly issue tracker <bugs@lists.dragonflybsd.org>
<http://bugs.dragonflybsd.org/issue676>
_____________________________________________________