Re: VESA module doesn't work with ATI Mach64 RagePro
It seems Cejka Rudolf wrote: > > Soren Schmidt wrote (1999/08/09): > > > It seems Kazutaka YOKOTA wrote: > > > There is a good possibility that the VESA BIOS extension for this card > > > is provided in a DOS TSR program and the VESA BIOS entry in the ROM > > > BIOS is just a stub. Such implementation is allowed in the VESA spec. > > > Actually its because the ATI chip reports the modes as non-VGA modes, > > which is correct (sortof), and our VESA code rejects those modeentries. > > Yes, thanks. Information reported by 0x4F01 function about any video > mode has set MODE_NON_VGA attribute indeed. And now I have found DOS TSR > program for VESA support... > > I hate VESA 2.0/3.0 specification :-( I hate ATI :-( Well well, no need to be that excited, if you hack out the test, the BIOS will willingly setup the modes that you get. And IIRC we can now support linear framebuffers in graphics modes, so support should be fairly easy to add.. > Is there any good AGP graphics card with full BIOS support in hardware? Dunno, but chances are getting smaller every day, most vendors relies on winblows drivers delivered with the cards nowadays.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA module doesn't work with ATI Mach64 RagePro
Soren Schmidt wrote (1999/08/09): > It seems Kazutaka YOKOTA wrote: > > There is a good possibility that the VESA BIOS extension for this card > > is provided in a DOS TSR program and the VESA BIOS entry in the ROM > > BIOS is just a stub. Such implementation is allowed in the VESA spec. > Actually its because the ATI chip reports the modes as non-VGA modes, > which is correct (sortof), and our VESA code rejects those modeentries. Yes, thanks. Information reported by 0x4F01 function about any video mode has set MODE_NON_VGA attribute indeed. And now I have found DOS TSR program for VESA support... I hate VESA 2.0/3.0 specification :-( I hate ATI :-( Is there any good AGP graphics card with full BIOS support in hardware? -- Rudolf Cejka ([EMAIL PROTECTED]; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 10-Aug-99 Brian F. Feldman wrote: > > I have a radio connected to line in on my sound card. > Then that would be playing during the entire bootup, wouldn't it? What, > does it play only after the card has been detected? The sound card shuts up after reset, and only starts outputing noise again after the sound card has been probed/attached. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: it's time...
On Tue, 10 Aug 1999, Daniel O'Connor wrote: > > On 10-Aug-99 Brian F. Feldman wrote: > > > Sure.. but you still have window of time where the audio is at its default > > > level before the rc stuff is run.. > > Why... would audio be playing from rc? Bear in mind, it would be set > > even before rc.local... > > I have a radio connected to line in on my sound card. Then that would be playing during the entire bootup, wouldn't it? What, does it play only after the card has been detected? > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 10-Aug-99 Brian F. Feldman wrote: > > Sure.. but you still have window of time where the audio is at its default > > level before the rc stuff is run.. > Why... would audio be playing from rc? Bear in mind, it would be set > even before rc.local... I have a radio connected to line in on my sound card. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: it's time...
> > On 09-Aug-99 Brian F. Feldman wrote: > > You guys don't see the point. The point is a single, simple place to put > > default mixer values for any number of devices, and fitting in with the > > current configuration file scenario. rc is the natural place for this, > > because _it_ gets run at startup. I just need to find somewhere to put > > this instead of rc.audio, because jkh vetoes it on that account... > > Sure.. but you still have window of time where the audio is at its default > level before the rc stuff is run.. > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > I didn't really mean to cause all this... I just wanted to have the mixer be at the levels I left it at when I shutdown the machine... I don't think we need all this argument about it. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Mon, 9 Aug 1999, Alex Zepeda wrote: > One could stuff it into rc.conf, but this means it's harder to > automagically save the state upon shutdown/reboot. But something like: Not really. You could do it with grep, awk, sed, or whatever you want, easily. The only possible problem would be... Getting it actually run at shutdown. > > deviceX_mixerdevice_vol = yy > > might work, and allow for multiple sound card. It's at http://janus.syracuse.net/~green/rc.audio.patch, not vapor :) > > - alex > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Tue, 10 Aug 1999, Daniel O'Connor wrote: > > On 09-Aug-99 Brian F. Feldman wrote: > > You guys don't see the point. The point is a single, simple place to put > > default mixer values for any number of devices, and fitting in with the > > current configuration file scenario. rc is the natural place for this, > > because _it_ gets run at startup. I just need to find somewhere to put > > this instead of rc.audio, because jkh vetoes it on that account... > > Sure.. but you still have window of time where the audio is at its default > level before the rc stuff is run.. Why... would audio be playing from rc? Bear in mind, it would be set even before rc.local... > > --- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
Hi, > MI> I've read Linux code (v2.2.9) closely, noticed they put cli > MI> before APM BIOS call and save & restore segment registers. I > MI> suspect these two (or only cli?) affect the suspending state. > MI> To clarify, could you try attached patches (for > MI> sys/i386/i386/bioscall.s) one by one? > > I've tried them all. They don't make a difference alas. > > In doing so, to my surprise I found out that when I suspend my computer > in FreeBSD, it isn't suspended at all! > > I have an ATX case with an Asus P2B motherboard. When I suspend my > computer, the power led starts flashing (and keeps doing so). > > When I suspend my computer in Linux or Windows, as mentioned, the > computer gets quiet (HDD spins down etc). The led flashes. Hmmm, the CLI call is not useful in this case... I also had another kind of problem about CLI, my box froze sometimes when suspending. It shouldn't be put CLI in here as Nate mentioned. Segment regisers also wasn't related with the problem. I watched %fs before & after BIOS call using ddb, the value didn't change on my box. I guess Linux code only expects some BIOSes manipulate segment registers. Another possibility is *delay mechanism* on suspend (and standby). AFAIK, Linux, NetBSD and PAO has this but CURRENT. I'll make patch tonight based on PAO APM code. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
Doug wrote in list.freebsd-current: > On Mon, 9 Aug 1999, Brian McGroarty wrote: > > > FWIW - I enabled APM over the weekend, configuring drives to > > spin down when not used for a good period of time. I get the > > message you list below, alternately with status 50 and 58, any > > time a drive needs to spin up. > > Thanks for the response. FWIW I have no apm enabled and these > drives don't have a chance to spin down since they're always busy when > under load. Do those drives happen to be IBM DeskStar drives? They spin down automatically when they have not been turned off for about a week, in order to clean the heads. It's a feature. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
[EMAIL PROTECTED] wrote: >> >> As far as I know, rc.shutdown doesn't get run unless you go to single >> user mode (for example, 'shutdown -h now' will not cause init to run >> rc.shutdown). I think FreeBSD-current was fixed and everytime run rc.shutdown. SEE GNATS DB bin/12093. http://www.freebsd.org/cgi/query-pr.cgi?pr=12093 MIHIRA Sanpei Yoshiro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 09-Aug-99 Brian F. Feldman wrote: > You guys don't see the point. The point is a single, simple place to put > default mixer values for any number of devices, and fitting in with the > current configuration file scenario. rc is the natural place for this, > because _it_ gets run at startup. I just need to find somewhere to put > this instead of rc.audio, because jkh vetoes it on that account... Sure.. but you still have window of time where the audio is at its default level before the rc stuff is run.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: it's time...
On Mon, 9 Aug 1999, Brian F. Feldman wrote: > You guys don't see the point. The point is a single, simple place to put > default mixer values for any number of devices, and fitting in with the > current configuration file scenario. rc is the natural place for this, > because _it_ gets run at startup. I just need to find somewhere to put > this instead of rc.audio, because jkh vetoes it on that account... One could stuff it into rc.conf, but this means it's harder to automagically save the state upon shutdown/reboot. But something like: deviceX_mixerdevice_vol = yy might work, and allow for multiple sound card. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
In message <[EMAIL PROTECTED]> Peter Mutsaers writes: : it, but I got suspicious because I'm running setiathome which accesses : the harddrive occasionally, and even during suspend mode I heard the : typical HDD sound sometimes. When I had my Libreto 50CT, I found that apm -Z (put into standby) would not work if there were any interrupts pending. These include any key releases that haven't happened by the time the suspend suspended, disk, serial I/O (I think, I only saw this once) and mouse I/O. If none of these things happened, it would standby correctly. I'm not sure what to do about this Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
>> "MI" == Mitsuru IWASAKI <[EMAIL PROTECTED]> writes: plm> In contract, if I suspend in Linux of Windows, the computer shuts up plm> immediateley and is quiet. Only sometimes there is a (not too loud) plm> little fan (I think it is the CPU fan) running for a few more minutes. MI> I've read Linux code (v2.2.9) closely, noticed they put cli MI> before APM BIOS call and save & restore segment registers. I MI> suspect these two (or only cli?) affect the suspending state. MI> To clarify, could you try attached patches (for MI> sys/i386/i386/bioscall.s) one by one? I've tried them all. They don't make a difference alas. In doing so, to my surprise I found out that when I suspend my computer in FreeBSD, it isn't suspended at all! I have an ATX case with an Asus P2B motherboard. When I suspend my computer, the power led starts flashing (and keeps doing so). When I suspend my computer in Linux or Windows, as mentioned, the computer gets quiet (HDD spins down etc). The led flashes. Now I found out that when I suspend it in FreeBSD (either with sleep 1; zzz or with the suspend button or through the BIOS timer), the led starts flashing, but processes just keep running! I never paid attention to it, but I got suspicious because I'm running setiathome which accesses the harddrive occasionally, and even during suspend mode I heard the typical HDD sound sometimes. So the problem is not an incomplete suspend, but no suspend at all. It seems to suspend at first, the led starts flashing, the screen is blanked, but somehow the computer keeps running. -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know [EMAIL PROTECTED] | the Netherlands| what I'm doing. ---+-+-- Powered by FreeBSD (-current). See http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error1)
On Mon, 9 Aug 1999, Brian McGroarty wrote: > FWIW - I enabled APM over the weekend, configuring drives to > spin down when not used for a good period of time. I get the > message you list below, alternately with status 50 and 58, any > time a drive needs to spin up. Thanks for the response. FWIW I have no apm enabled and these drives don't have a chance to spin down since they're always busy when under load. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wd0: interrupt timeout (status 58 error 1)
FWIW - I enabled APM over the weekend, configuring drives to spin down when not used for a good period of time. I get the message you list below, alternately with status 50 and 58, any time a drive needs to spin up. Myself, I'm curious about why the access light stays on on just one of the three hard drives once it's gone to sleep and come up again. The identical hard drive on the primary drive controller doesn't exhibit this behavior. --- Doug <[EMAIL PROTECTED]> wrote: > I'm starting to see the following errors more frequently on > my 3 > servers running current dated July 30. > > Aug 6 14:08:36 /kernel: wd0: interrupt timeout > (status 58 error 1) > Aug 6 14:08:38 /kernel: wd0: wdtimeout() DMA > status 4 _ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wd0: interrupt timeout (status 58 error 1)
I'm starting to see the following errors more frequently on my 3 servers running current dated July 30. Aug 6 14:08:36 /kernel: wd0: interrupt timeout (status 58 error 1) Aug 6 14:08:38 /kernel: wd0: wdtimeout() DMA status 4 All 3 servers locked up over the weekend, although I have a feeling that the problem that locked them up was an nfs mount problem (more to come on that one when I get the details). However any insights into this wd problem are welcome. All 3 servers are custom boxes running intel N440BX mb's, dual PIII-500's, 512 megs of ram and (unfortunately) a mixture of quantum and western digital IDE hard disks. Here's a dmesg quote from one of them: 9671MB (19807200 sectors), 19650 cyls, 16 heads, 63 S/T, 512 B/S Unless someone has something for me to check I'm going to try upgrading my -current today and see if that helps. These messages seem to be coming concurrent with time periods where the boxes enter heavy swapping, although it's tough to tell which one (or even if) is causing the other. Other tests indicate that the swapping problems are caused by some errant CGI scripts, which is what the boxes are set up to handle (cgi in general, not errant ones :). TIA, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
Daniel O'Connor wrote: > > On 09-Aug-99 Alex Zepeda wrote: > > Actually at shutdown would be cool. So it could save the current > volumes, > > and restore them at startup. Altho, at suspend and resume time > wouldn't > > be a bad idea either. > > You could do it something like the way boot -c stuff or the splash > screen is > done, ie load a 'module' which is just a text file for the sound system > to > parse.. > > Don't know how you'd go unload'ing and load'ing the file though. Wouldn't it be just like a splash screen? kldload volume.conf -t volume_data (or whatever) -- Eric Hodel [EMAIL PROTECTED] "They cook your gonies" -Terry Lambert's uncle on why he doesn't have a microwave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PCI bus on 486/66 no longer detected
Today I thought I would upgrade my 4.0 box from a July 15th snapshot to an August 9th snapshot. Only problem is I can't, because the August 9th snapshot's boot kernel refuses to locate my 486's PCI bus. Previously, the bus was detetected as follows: pcib0: on motherboard pci0: on pcib0 chip0: at device 0.0 on pci0 tl0: irq 9 at device 13.0 on pci0 tl0: Ethernet address: 00:80:5f:9a:58:f1 xl0: <3Com 3cSOHO100-TX OfficeConnect> irq 12 at device 14.0 on pci0 xl0: Ethernet address: 00:10:5a:e3:60:9c xl0: autoneg complete, link status good (half-duplex, 100Mbps) pciconf -l shows the following: mcmillan# pciconf -l chip0@pci0:0:0: class=0x068000 card=0x chip=0x884910e0 rev=0x02 hdr=0x00 tl0@pci0:13:0: class=0x028000 card=0x chip=0xf1300e11 rev=0x10 hdr=0x00 xl0@pci0:14:0: class=0x02 card=0x764610b7 chip=0x764610b7 rev=0x30 hdr=0x00 No, I didn't change any hardware setting anywhere. The older kernel still boots and works properly (I couldn't install the new snapshot because I need to do a network install, and my network cards are PCI). I have no idea where to look for the problem. Anybody have any bright ideas? -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
> > As far as the segment registers, we do an explicit save of them already > > when we switch into VM86 mode, so it should be necessary to save them > > twice. > > VM86 mode is only used to enable APM; after that we are using the > 32-bit protected mode interface. Ahh... In the old code, we used to explicitly push/pop all of the registers. Do we still do that? Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
> As far as the segment registers, we do an explicit save of them already > when we switch into VM86 mode, so it should be necessary to save them > twice. VM86 mode is only used to enable APM; after that we are using the 32-bit protected mode interface. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
Cameron Grant wrote: > > to let newpcm out of the cage so you can all get your grubby little hands on > it. > > http://www.vilnya.demon.co.uk/newpcm+dfrpnp-19990807.diff.gz > > this is a patch against a recent -current. if you have a pci or isapnp > soundcard, you should have pnp0 and pcm0 in your kernel config as > appropriate. isapnp cards should not need any pnp lines in kernel.conf. > > the list of supported cards is as for luigi's driver, with the addition of a > couple more mss-clones, and trident 4dwave. there is a part done aureal > vortex driver which is as yet nonfunctional. mmap() is supported but not > well tested. format conversions are supported. the code seems to be > stable. > > please test it and email me success and failure reports. > > - cameron Hi, First, I'd like to thank Cameron for his great work on the pcm driver. It builds and installs cleanly, and generally looks very impressive. I apologize in advance if the following message is a bit on the long side, but the problem I'm going to describe is very odd. I must also make clear that the sound card works fine under Windoze, and it also worked fine with the old pcm driver, until something got broken around 20 April this year (_after_ the integration of new bus). The sound card settings are changeable in the BIOS; this is what I have (the card is a non-PnP Yamaha): Sound: Enabled (other options are: Disabled and Auto) SB I/O address: 220-22F WSS I/O address:530-538 Adlib I/O address: 388-38F MPU I/O address:300-301 CTRL I/O address: 100 (OPL3 chip control) DMA A: DMA 1 (other options: 0,7) DMA B: DMA 0 (other options: 1,7) IRQ:IRQ 5 In accordance with these settings, I used the following line in the kernel: device pcm0 at isa? port 0x530 irq 5 drq 1 flags 0x10 (Note the order of the DMA channels - 1, then 0) Now this is what happens: the driver successfully detects the card, but fails to register an interrupt: /kernel: mss_detect - chip revision 0x0a /kernel: mss_detect() - Detected CS4231 /kernel: pcm0: at port 0x530-0x53f,0x310-0x311 irq 5 drq 1 flags 0xa210 on isa0 /kernel: pcm: setmap 3, ff00; 0xc7bdd000 -> 3 /kernel: pcm: setmap 4, ff00; 0xc7bed000 -> 4 /kernel: device combination doesn't support shared irq3 /kernel: intr_connect(irq3) failed, result=-1 /kernel: device combination doesn't support shared irq4 /kernel: intr_connect(irq4) failed, result=-1 /kernel: device combination doesn't support shared irq5 /kernel: intr_connect(irq5) failed, result=-1 /kernel: device combination doesn't support shared irq7 /kernel: intr_connect(irq7) failed, result=-1 /kernel: device combination doesn't support shared irq9 /kernel: intr_connect(irq9) failed, result=-1 /kernel: device combination doesn't support shared irq12 /kernel: intr_connect(irq12) failed, result=-1 /kernel: device combination doesn't support shared irq14 /kernel: intr_connect(irq14) failed, result=-1 /kernel: device combination doesn't support shared irq15 /kernel: intr_connect(irq15) failed, result=-1 IRQ 5 is definitely unused, and exactly the same setup worked fine with the old pcm driver. Another strange thing is that cat /dev/sndstat shows: FreeBSD Audio Driver (newpcm) Aug 8 1999 21:55:41 Installed devices: pcm0: at io 0x530 irq 5 drq 1:0 (1/1 channels duplex) as if everything were ok. It also seems that although intr_connect fails, IRQ 5 is marked as being in use, because pcic then chooses the next one available (10): /kernel: PC-Card VLSI 82C146 (5 mem & 2 I/O windows) /kernel: pcic: controller irq 10 Now the VERY odd thing: if I use DMA channels 0 and 1 (as opposed to 1 and 0), change the BIOS settings accordingly, and compile the kernel with device pcm0 at isa? port 0x530 irq 5 drq 0 flags 0x11 I get the following error: /kernel: mss_detect - chip revision 0x0a /kernel: mss_detect() - Detected CS4231 /kernel: pcm0: at port 0x530-0x53f,0x310-0x311 irq 5 flags 0xa211 on isa0 + /kernel: device_probe_and_attach: pcm0 attach returned 6 /kernel: device combination doesn't support shared irq3 /kernel: intr_connect(irq3) failed, result=-1 /kernel: device combination doesn't support shared irq4 /kernel: intr_connect(irq4) failed, result=-1 /kernel: device combination doesn't support shared irq7 /kernel: intr_connect(irq7) failed, result=-1 /kernel: device combination doesn't support shared irq9 /kernel: intr_connect(irq9) failed, result=-1 /kernel: device combination doesn't support shared irq12 /kernel: intr_connect(irq12) failed, result=-1 /kernel: device combination doesn't support shared irq14 /kernel: intr_connect(irq14) failed, result=-1 /kernel: device combination doesn't support shared irq15 /kernel: intr_connect(irq15) failed, result=-1 /kernel: PC-Card VLSI 82C146 (5 mem & 2 I/O windows) + /kernel: pcic: controller irq 5 and cat: /dev/s
Re: it's time...
You guys don't see the point. The point is a single, simple place to put default mixer values for any number of devices, and fitting in with the current configuration file scenario. rc is the natural place for this, because _it_ gets run at startup. I just need to find somewhere to put this instead of rc.audio, because jkh vetoes it on that account... Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
> plm> In contract, if I suspend in Linux of Windows, the computer shuts up > plm> immediateley and is quiet. Only sometimes there is a (not too loud) > plm> little fan (I think it is the CPU fan) running for a few more minutes. > > I've read Linux code (v2.2.9) closely, noticed they put cli > before APM BIOS call and save & restore segment registers. The CLI call is bogus. I note a commit I *just* made: revision 1.49.2.4 date: 1999/07/10 18:36:59; author: nate; state: Exp; lines: +1 -2 - Remove un-necessary CLI statement from apm_int, which casues suspend/resume to fail on at least some IBM Thinkpads. [ FWIW, the cli call is also missing from -current ] Submitted by: "Kenton A. Hoover" <[EMAIL PROTECTED]> If the CLI is there, my box refuses to suspend. Apparently it was removed from linux a while back, and like many software projects that don't have usable history, the bug is now being re-introduced into Linux again. :( As far as the segment registers, we do an explicit save of them already when we switch into VM86 mode, so it should be necessary to save them twice. > I suspect these two (or only cli?) affect the suspending state. > To clarify, could you try attached patches (for sys/i386/i386/bioscall.s) > one by one? I'd be interested to know if either of the patches did anything... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vty3 and 4.0 snap 080799
I just downloaded the latest snap (080799) and tried installing it. When getting to the media section and configuring ppp for a ftp install, I try going to vty3 (alt-f3). However, that vty is not available. I have tried this 3 times now. Is this broken? I did a search for this but have found nothing. Thanks, Mike [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: recent apm changes
plm> In contract, if I suspend in Linux of Windows, the computer shuts up plm> immediateley and is quiet. Only sometimes there is a (not too loud) plm> little fan (I think it is the CPU fan) running for a few more minutes. I've read Linux code (v2.2.9) closely, noticed they put cli before APM BIOS call and save & restore segment registers. I suspect these two (or only cli?) affect the suspending state. To clarify, could you try attached patches (for sys/i386/i386/bioscall.s) one by one? # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # bioscall-1 # bioscall-2 # bioscall-3 # echo x - bioscall-1 sed 's/^X//' >bioscall-1 << 'END-of-bioscall-1' X--- i386/i386/bioscall.s.org Mon Aug 9 17:51:31 1999 X+++ i386/i386/bioscall.s Mon Aug 9 17:53:07 1999 X@@ -64,9 +64,16 @@ X movl12(%ebp),%edx X movl16(%ebp),%esi X movl20(%ebp),%edi X+#if 1 /* cli hack */ X+ pushfl X+ cli X+#endif X pushl %ebp X lcall _bioscall_vector X popl%ebp X+#if 1 /* cli hack */ X+ popfl X+#endif X movl%eax,0(%ebp) X movl%ebx,4(%ebp) X movl%ecx,8(%ebp) END-of-bioscall-1 echo x - bioscall-2 sed 's/^X//' >bioscall-2 << 'END-of-bioscall-2' X--- i386/i386/bioscall.s.org Mon Aug 9 17:51:31 1999 X+++ i386/i386/bioscall.s Mon Aug 9 18:01:36 1999 X@@ -64,9 +64,17 @@ X movl12(%ebp),%edx X movl16(%ebp),%esi X movl20(%ebp),%edi X+#if 1 /* segment regs hack */ X+ pushl %fs X+ pushl %gs X+#endif X pushl %ebp X lcall _bioscall_vector X popl%ebp X+#if 1 /* segment regs hack */ X+ popl%gs X+ popl%fs X+#endif X movl%eax,0(%ebp) X movl%ebx,4(%ebp) X movl%ecx,8(%ebp) END-of-bioscall-2 echo x - bioscall-3 sed 's/^X//' >bioscall-3 << 'END-of-bioscall-3' X--- i386/i386/bioscall.s.org Mon Aug 9 17:51:31 1999 X+++ i386/i386/bioscall.s Mon Aug 9 18:00:07 1999 X@@ -64,9 +64,20 @@ X movl12(%ebp),%edx X movl16(%ebp),%esi X movl20(%ebp),%edi X+#if 1 /* cli + segment regs hack */ X+ pushfl X+ cli X+ pushl %fs X+ pushl %gs X+#endif X pushl %ebp X lcall _bioscall_vector X popl%ebp X+#if 1 /* cli + segment regs hack */ X+ popl%gs X+ popl%fs X+ popfl X+#endif X movl%eax,0(%ebp) X movl%ebx,4(%ebp) X movl%ecx,8(%ebp) END-of-bioscall-3 exit To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
> On Mon, 9 Aug 1999, Daniel O'Connor wrote: > > > You could do it something like the way boot -c stuff or the splash screen is > > done, ie load a 'module' which is just a text file for the sound system to > > parse.. > > > > Don't know how you'd go unload'ing and load'ing the file though. > > Why that complex? Couldn't I just drop in a small script using awk and > sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a > small C program would suffice if scripting isn't your cup of tea. > > - alex As far as I know, rc.shutdown doesn't get run unless you go to single user mode (for example, 'shutdown -h now' will not cause init to run rc.shutdown). Personally, I put my mixer settings in ~/.mixerrc, and load/save values there by running a script from ~/.xinitrc (load before starting window manager, save after window manager exits). But I never have a real need to use audio when I'm not running X (and no need to have any mixer settings before logon). Daniel ~~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Mon, 9 Aug 1999, Daniel O'Connor wrote: > > Why that complex? Couldn't I just drop in a small script using awk and > > sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a > > small C program would suffice if scripting isn't your cup of tea. > > Hmm.. true.. so have a shell script to write the file on shutdown, then load > the file as a kernel mod on startup using the boot loader? > > That way you don't have that annoying window of time after the card has been > initialised before /etc/rc is run :) Wha? Since neither the kernel nor the startup scripts really frob the sound devices much, another shell script could suffice for this too, no? I mean, I usually have to wait until after I've logged in to turn down the volume anyways. This could even be implemented (perhaps easier) thru the rc.d tree. Perhaps I'll do that tomorrow, and make a port out of it ;) Or am I just oversimplifying things? - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Mon, 9 Aug 1999, Daniel O'Connor wrote: > You could do it something like the way boot -c stuff or the splash screen is > done, ie load a 'module' which is just a text file for the sound system to > parse.. > > Don't know how you'd go unload'ing and load'ing the file though. Why that complex? Couldn't I just drop in a small script using awk and sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a small C program would suffice if scripting isn't your cup of tea. - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 09-Aug-99 Alex Zepeda wrote: > Why that complex? Couldn't I just drop in a small script using awk and > sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a > small C program would suffice if scripting isn't your cup of tea. Hmm.. true.. so have a shell script to write the file on shutdown, then load the file as a kernel mod on startup using the boot loader? That way you don't have that annoying window of time after the card has been initialised before /etc/rc is run :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Vinum RAID-5 broken
I seem to have broken something in Vinum's RAID-5 support while importing it to the source tree. It works fine when all disks are up, but things go to hell in degraded mode. I'll have it fixed in a day or two, but in the meantime don't try testing degraded mode: it don't work. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Sun, 8 Aug 1999, Mike Smith wrote: > > On Sun, 8 Aug 1999, Brian F. Feldman wrote: > > > > > > It works ok for me, but one nice feature of the sound system would be if > > > > upon shutdown (I don't leave my machine on all the time right now) OS > > > > somehow looked at a config file (call it /etc/soundvol.conf) for mixer > > > > volumes, and set them to that as a default... Just an idea. > > > > > > Don't you mean upon startup? If so, see my recent rc proposition for mixer > > > settings. > > > > Actually at shutdown would be cool. So it could save the current volumes, > > and restore them at startup. Altho, at suspend and resume time wouldn't > > be a bad idea either. > > Gosh, let's see; at shutdown it could edit /etc/rc.conf. Wouldn't that > be handy? And so easy too. 8) Nah, it could store the values in, say, /etc/mixerX.vols, if the knob was enabled in rc.conf. Imagine for a moment one less thing to remember to tweak at boot time. Sure my AWE64 and 32PnP don't need tweaking upon startup if I don't mind waking everyone up when I play an mp3, but there are cards out there that default to a volume of zero. Sure it's nothing monumental, but it's a convience thing. I mean, if the FreeBSD project is opposed to convenience, why have /usr/local/etc/rc.d, or even rc.conf for that matter when one can enter this stuff in by hand each time at startup %) - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
