|
|
Post by musicman on Dec 15, 2010 16:08:14 GMT -5
Sorry for the title; didn't want this to get any more confusing than it already is.
As I was trying the second computer - with the Intel D845WN motherboard, checking the BIOS - I realized something.....I had forgotten that I had swapped motherboards in this system about a month ago, because I have hardly used it since then. The previous & replacement motherboards were BOTH Intel D845WN. HOWEVER, - ALL of the BIOS Settings were default, meaning the Interrupt was still at Automatic, and the Onboard Audio [AC97] was still at ENABLED. Also, in this system, the E-MU audio card is inserted into PCI slot #2 (the same slot as in the Intel D845PESVL)]
Anyway, upon starting in THIS system, with the latest KNOSB3 download from yesterday, it does hang...with the following information near the end AND with the onboard AC97 DISABLED:
{am having to switch monitor/monitor/mouse back and forth to type this...}
intpin=a, irq=22 powerspec 2 supports D0 D1 D2 D3 current D0
pci3: driver added
pci0: driver added
pci1: driver added
pci2: driver added
found-> vendor=0X1102, dev-0x004, revid-0X03, domain=0, bus=2, slot=10, function=0, class=04-01-00, hdrtype=0x00, mfdev=1, cmdreg=0x0105, statreg=0x0290, cachelnsz=0 (dwords), lattimer=0x20 (960ns), mingnt=0x02 (500ns), maxlat=0x14 (5000ns), intpin=a, irq=22 powerspec 2 supports D0 D1 D2 D3 current D0
pci0:2:10:0 reprobing on driver added
pcm0: <Creative Audigy (EMU10K2)> port 0xdf40-0xdf5f irq 22 at device 10.0 on pci2
pcm0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xdf40
emu: setmap (1554e000, 800), nseg=1 error=0
emu: setmap (1554f000, 1000), nseg=1 error=0
pcm0: AC97 timed out
pcm0: ac97 codec invalid or not present (id == 0)
device_attach: pcm0 attach returned 6
pci3: driver added
at this point, it hangs.....
on the EMU10K2 [WN] computer, in windows, device manager gives E-MU E-DSP
an input I/O of 0000DF40-0000DF5F, with an interrupt IRQ PCI 22, no other devices conflicting or sharing.
on the EMU10K1 [PESV] computer [the previous one I sent you the diagnostics file from], in windows, device manager gives E-MU E-DSP
an input I/O of 0000DC00-0000DC1F, with an interrupt IRQ PCI 22, no other devices conflicting or sharing.
|
|
|
|
Post by Kevin McAleavey on Dec 16, 2010 1:54:39 GMT -5
Sorry for the title; didn't want this to get any more confusing than it already is. As I was trying the second computer - with the Intel D845WN motherboard, checking the BIOS - I realized something.....I had forgotten that I had swapped motherboards in this system about a month ago, because I have hardly used it since then. The previous & replacement motherboards were BOTH Intel D845WN. HOWEVER, - ALL of the BIOS Settings were default, meaning the Interrupt was still at Automatic, and the Onboard Audio [AC97] was still at ENABLED. Also, in this system, the E-MU audio card is inserted into PCI slot #2 (the same slot as in the Intel D845PESVL)] Anyway, upon starting in THIS system, with the latest KNOSB3 download from yesterday, it does hang...with the following information near the end AND with the onboard AC97 DISABLED: {am having to switch monitor/monitor/mouse back and forth to type this...} (snipped stuff to reduce size of reply box) at this point, it hangs..... on the EMU10K2 [WN] computer, in windows, device manager gives E-MU E-DSP an input I/O of 0000DF40-0000DF5F, with an interrupt IRQ PCI 22, no other devices conflicting or sharing. on the EMU10K1 [PESV] computer [the previous one I sent you the diagnostics file from], in windows, device manager gives E-MU E-DSP an input I/O of 0000DC00-0000DC1F, with an interrupt IRQ PCI 22, no other devices conflicting or sharing. For reasons I need to figure out, the PCI bus is still reporting the HDA device as existing which of course it shouldn't. But it is.  The sound detect and driver handling is KNOS code and an unexpected outcome. With that still disabled, can you shoot me an email with the diags file? Reason I need the whole thing is that down towards the end is "pciconf" data and I need to look that over. For some reason, BIOS is leaving the PCI bus *lit* with that card reported as enabled and that's why our detector is finding it even if BIOS reports it off. My guess is that Windows is also reporting it since disabled devices shouldn't be showing up at all. From that info I can see how we can improve our detect code to fail properly on a kernel attach failure and ignore devices that aren't supposed to exist when BIOS fails to do that. That's what's going on. Once you've gotten the diags file to me, try going back into BIOS and turn that built in HDA sound *ON* ... what I *expect* to happen is that KNOS will load BOTH drivers and enable BOTH sound devices without any problems. And of course, using a second volume control applet on the top panel, you can squelch the card you don't want used. Fingers and other appendages crossed that this will at least give you a workaround until I can figure that out. It will require new code from me though to do that. Seriously ... THANKS for the quirk! I'm glad we're seeing this NOW and not later ... |
|
|
|
Post by musicman on Dec 16, 2010 21:16:20 GMT -5
OK - that all makes sense - your explanation. On this particular system in question [WN] the bootup process completely halted at the end of the code I sent to the forum thread earlier. Have tried it several times - same results. So I never can even get into KNOS to get the diag created.
HOWEVER - on the original computer [PESVL] That is the system from which i sent you the earlier diag file. I will go ahead and create 2 new diag's - one with the AC97 enabled in BIOS, the other with the AC97 DISABLED in BIOS. I am working on something else right now, and am also involved in a day-long chase with a 4-year-old [she giggles and runs faster than greased lightning]. I will try to get things to a pause so that I can go ahead and do this tonight, or tomorrow at the latest.
I have NEVER seen any trace of the AC97 audio chip in the Windows Device Manager at any time since the computers were built; EXCEPT for one time when I was trying to find a glitch, and reinstalled Windows with the barest-bones I could, adding all PCI cards etc. AFTER Windows had completely loaded - been updated - serviced packed ...then added all peripherals just before re-registering/reactivating. As soon as I disable the AC97 in BIOS, it STAYS undiscovered by Windows [or, at least, unreported anywhere that I can find].
I HAVE had occurrences through the years, on my own computers and on those of others, where the BIOS would have something disabled, and Windows WOULD see it and enable it, or try to....just as you described. Just never the AC97 onboard audio. And I just remembered - before I installed the E-MU audio card, I used an M-Audio Delta Audiophile 2496 [which I still have]. With the M-Audio card installed, the AC97 was also disabled in the BIOS, and was never shown up as detected by Windows.
|
|
|
|
Post by Kevin McAleavey on Dec 17, 2010 4:02:17 GMT -5
OK - that all makes sense - your explanation. On this particular system in question [WN] the bootup process completely halted at the end of the code I sent to the forum thread earlier. Have tried it several times - same results. So I never can even get into KNOS to get the diag created. HOWEVER - on the original computer [PESVL] That is the system from which i sent you the earlier diag file. I will go ahead and create 2 new diag's - one with the AC97 enabled in BIOS, the other with the AC97 DISABLED in BIOS. I am working on something else right now, and am also involved in a day-long chase with a 4-year-old [she giggles and runs faster than greased lightning]. I will try to get things to a pause so that I can go ahead and do this tonight, or tomorrow at the latest. I have NEVER seen any trace of the AC97 audio chip in the Windows Device Manager at any time since the computers were built; EXCEPT for one time when I was trying to find a glitch, and reinstalled Windows with the barest-bones I could, adding all PCI cards etc. AFTER Windows had completely loaded - been updated - serviced packed ...then added all peripherals just before re-registering/reactivating. As soon as I disable the AC97 in BIOS, it STAYS undiscovered by Windows [or, at least, unreported anywhere that I can find]. I HAVE had occurrences through the years, on my own computers and on those of others, where the BIOS would have something disabled, and Windows WOULD see it and enable it, or try to....just as you described. Just never the AC97 onboard audio. And I just remembered - before I installed the E-MU audio card, I used an M-Audio Delta Audiophile 2496 [which I still have]. With the M-Audio card installed, the AC97 was also disabled in the BIOS, and was never shown up as detected by Windows. We do things a little differently, and so does BSD. In KNOS, we're presented with a very interesting challenge. A "public distribution" that has to have the smarts to be able to figure out what it's been started on, what drivers it needs, all without asking the "user" to download anything nor configure anything so that it can figure out all by itself how to wake itself up fully working. It's an incredibly formidable task unlike BSD as OSX on Apple where the hardware possibilities are *insanely* limited. KNOS has to have the "smarts" to figure out how to work and there's complications aplenty in making that all happen reliably every time. So we ask BIOS "whatcha got?" and establish a list of what BIOS says is lit. We also scan the PCI or whatever bus is in the machine and get a listing of that. We also check for numerous possibilities of other hardware and make a list of everything. Then from there, we whittle down the information and then KNOS configures itself on a "best guess" based on a lengthy proprietary database of our own design, coupled with a few years of our research into all the possible hardware that can exist and uses that to wake up and fling up a desktop automagically. After all these years, VERY few surprises. If we were to be able to do what Google is doing with their "Chrome OS" in working with specific manufacturers and establishing a highly limited operating system to work on hardware from specific manufacturers and specific configurations just like Apple has done, this would be OH so easy. But our design philosophy is "any relatively recent machine in existence" and that requires an awful lot of "smarts" to not get fooled and bring KNOS up properly no matter what. I think we've done pretty well there so far but we know there are still some surprises out there, thus this beta program. BIOS is telling us, as well as the PCI probe that the AC97 (HDA) device is there and apparently the design of those motherboards has its interrupts established for your sound card as installed as NMI's (NON-Maskable Interrupt) and as such, it's going to show up even if it's supposedly squelched. Problem for you is that we weren't aware of the need to mask it again in KNOS since the motherboard isn't doing that as expected. No biggie. Since this turned up, I've already reworked the code I wrote to hit on the first non-motherboard sound card found and exit the detect sequence on the logical basis of "if there's another sound card other than the one on the motherboard, they must want that one." Heh. I've already got the code written, but that's going to require another build. So problem already solved, but the current beta won't help since that can't be adjusted there. BSD and Linux are designed to be futzed with. End user is expected to know coding well enough to figure out their own hardware, recompile the kernel and edit configuration files until the cows come home to customize the distribution for their specific hardware. Linux makes it somewhat easier than BSD though because BSD is an OS strictly oriented towards servers (and they do NOT encourage its use as a desktop at all) whereas Linux at least makes somewhat of an attempt to not be entirely "desktop hostile." It's been QUITE the challenge to turn BSD into a useful end-user desktop without the need for the end user to do anything at all other than start it up. That's what we hope to eventually get paid for here ... The good news for you though is that I've already found the problem and why it's happening and have already written new code to solve it. Because of this though, I'm also reworking all of our OTHER "smarts" for other hardware to prevent a similar conflict from occurring elsewhere. There's little I can do about BSD kernel issues since we need to keep the kernel code pure for "trustworthiness" but I'm certainly free to fix any code that WE have written, and this is one of ours thankfully. NEXT release will have the necessary fixes! BTW: Did you try enabling the AC97 to see if things work as I expect they might? I'm holding off on finishing my own reworks on this end until I know whether that makes any difference ... Our smarts weren't quite smart enough though to figure THIS one out. |
|
|
|
Post by Kevin McAleavey on Dec 17, 2010 5:41:25 GMT -5
I am working on something else right now, and am also involved in a day-long chase with a 4-year-old [she giggles and runs faster than greased lightning]. I will try to get things to a pause so that I can go ahead and do this tonight, or tomorrow at the latest. Whoops! Missed this since I was so heavily in "geek mode" and dealing with the code - caused me to miss entirely the "human side" of the equation. Apologies! Disregard my previous question as to the diagnostics - I can fully understand your issues there. Heh. Take your time, and hunt only when ready ... this can wait. |
|
|
|
Post by musicman on Dec 17, 2010 12:33:00 GMT -5
glad to hear that you're able to understand all of this, and that my messing around with everything might have helped with other things down the road. I also like and appreciate your explanation of how how BSD searches the motherboard. I might not understand the coding part, but I do have the computers I have worked with and built from the ground up, and several peripherals - both internal and external - which I have acquired, and keep "just in case".
THIS is the system which hangss after reading the audio drivers. Changing the BIOS settings didn't make a difference. Probably the new build will have the fixes for that.
I have already sent you the diags - 4 - for the other computer - the PESVL. Comments in the thread for EMU10K1 thread
|
|
|
|
Post by Kevin McAleavey on Dec 18, 2010 0:07:52 GMT -5
glad to hear that you're able to understand all of this, and that my messing around with everything might have helped with other things down the road. I also like and appreciate your explanation of how how BSD searches the motherboard. I might not understand the coding part, but I do have the computers I have worked with and built from the ground up, and several peripherals - both internal and external - which I have acquired, and keep "just in case". THIS is the system which hangss after reading the audio drivers. Changing the BIOS settings didn't make a difference. Probably the new build will have the fixes for that. I have already sent you the diags - 4 - for the other computer - the PESVL. Comments in the thread for EMU10K1 thread Thanks for doing all that! I'm going to need a bit more time to wade through it all because it appears as of this moment that the problem isn't in MY code, but some kind of weirdness in the kernel stuff or the EMU driver. I was under the impression when I saw the PCM/AC97 stuff that we were seeing the motherboard's audio card but it appears that the EMU is using the same chipset. When you turned on the motherboard's audio though it appeared as a second device and according to the diagnostics, loaded up fully - fat, dumb and happy and would have worked. So that error you're seeing is indeed in the EMU handling as opposed to what I had originally thought was going on. At this point I don't know quite what the problem is, and there's a lot of backtrace to wade through. So until we can dig a bit further, I'm going to take this to email with you since there's a bunch of things I'm going to need to try with you to figure out what we can do and no sense in loading up here until we have an answer that will be of benefit to anyone else reading through here. So please bear with me, I'm on it ... but don't quite know where to go next as yet. You'll hear from me later in email. |
|
