Re: emu10k1 problems solved
Alexander Sanda wrote: At 09:15 07.08.2000 +0200, Benedikt Schmidt wrote: Just wanted to say that with the recent changes in the emu10k1 driver all my problems with it have disappeared. There are no more "dodgy irq" messages and the sound quality has improved too (no more crackling). Just a quick question... Is it possible to get this driver working under 4.1-STABLE aswell, or are the changes in the -current kernel already too big? Or is it officially planned to merge this updated driver into the -STABLE branch? Grab /sys/dev/sound/pci/emu10k1.c and /sys/gnu/dev/sound/pci/emu10k1.h from -current and recompile kernel.. no problems. -mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vga0, atkbdc0, fdc0 attaching to ISA bus?
"Brandon D. Valentine" wrote: On Sun, 6 Aug 2000, Donn Miller wrote: Anyone know why these devices want to attach to the ISA bus on a primarily PCI bus machine? My MoBo is an Asus SP97-V, which has a mixture of ISA and PCI slots. I was wondering maybe if even machines that have all PCI slots, that there's still an internal ISA bus? Check out my dmesg. I've got a machine with an Abit SL6 w/ AGP/PCI/CNR onboard, but no ISA slots, and it still has an ISA to PCI bridge built in. Some of the devices still register with the kernel on the ISA bus, even though they are quite obviously connected to the PCI bus. I suspect that some of these devices may be tied to the ISA bus in the BIOS for arcane PC/AT reasons. I would be interested to know details though, if someone could spare a moment to give an over-the-top explanation of why this is true. I'm working on a little util similar to pciconf -l right now.. but using a large array of vendor/device strings for the id's.. Does pciconf -l display those devices as being part of the PCI bus or are they out of the picture completely? -mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When Good DIMMS go Bad (or how I fixed my sig11)
Stephen Hocking wrote: About a week ago, I complained of mysterious Sig 11s during a make world. After some experimentation, a PC100 DIMM was found to be better suited for a 66MHz memory bus in another machine, who obligingly donated a DIMM in return that actually works with a 100MHz bus. I think the trip from Australia and this Texas heat finally pushed the dodgy one over the edge. Have you tried any memory testing routines such as memtest86 ? Its the only you write to a floppy and it runs before any bootstrap kicks in -- independant of the OS -- and takes around 18 hours for a single pass. It appears to be quite a comprehensive torture test. If so, how did that dodgy DIMM perform? (The reason I ask is that I'm interested in knowing if these tests can reveal the problems that building world did in your situation.) -mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: To MFC or not to MFC, that is the question.
Good greif that last one failed to go to stable@ or current@.. time to fix mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: To MFC or not to MFC, that is the question.
"Jordan K. Hubbard" wrote: Really, then you have a short memory. Why don't we ask Jordan for a clarification. How about if you let me review the patches in question and I'll render a decision. If you, Matt, could put the SMP and linux stuff into -current first and then give me a day or so to check it out, I'll submit my own opinion on whether or not this is "immediate MFC" material. That covers the operational side of the discussion, and on the procedural side I unfortunately see a lot of arguing about "our policy" for things like this in spite of the fact that there has never really been an absolutely clear-cut mandate about when/where things should be MFC'd. It's a more complex mesh of judgement calls revolving around: o Whether the change is absolutely mandated by security criteria or just-plain-brokenness in -stble. o Whether the change is cosmetic or otherwise minor enough that there's no reason not to Just Do It right away. o How close we are to an impending release in the -stable branch in question. As has been stated frequently in the past, the release engineer would prefer for big changes in -stable to come along early in the game for maximum testing time rather than the day before code freeze starts. Determining where one sits with respect to all three of these merge-justification criteria comes down to a judgement call in each case, not some precise committer's checklist. I also personally don't mind that too much since no checklist can be written to cover all cases or codify the full range of "good judgement", so it ultimately comes down to personal opinion. I see two very big differences of personal opinion on this one and am willing to arbitrate between the two. In the longer-term, this kind of thing should be handled by the architecture group or the conflict-resolution committee depending on whether it's an architectural dispute or a simple clash between personalities or styles. In this case, I'd say it was a job for the CRC if we currently had one. :) me too I'll be your CRC and say stop yer bickering and discuss this like adults (assuming you both are infact classed as such) which means no cheap shot insults (im sure you both have great memories and excusing that would be your workloads which im sure are right up there) and getting over whatever personal differences either party might have. ok good! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
Nate Williams wrote: I was under the impression that 4.x hasn't been designated as the stable branch (yet). That will happen when 4.1 is released, but until that happens 3.x is still considered the -stable release. That would kinda make sense since cvsuping with tag=RELENG_3 seems to give me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000).. But besides that, this whole back and forth dont-do-this-do-that charade is going to get pretty juvenile soon.. I mean we're (matt) already at bad memory insults heh so how bout you both kiss/reevaluate and make up before it gets so bad you try to keep away from each other next time you're both at one of these conventions or whatever.. hmm now theres an uncomfortable situation to be in for both sides. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
Mike Muir wrote: Nate Williams wrote: I was under the impression that 4.x hasn't been designated as the stable branch (yet). That will happen when 4.1 is released, but until that happens 3.x is still considered the -stable release. That would kinda make sense since cvsuping with tag=RELENG_3 seems to give me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000).. Ok wait im a moron.. been using the stable-supfile instead of the 4.x-stable-supfile.. hm. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make World dies.......
William Woods wrote: Shit, I will loose all my custom settings...no other way around this Try compiling and installing the kernel first, reboot, buildworld.. should work (did for me but hey, im x86..) NO PROMISES! heh mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: intpm0: Could not allocate Bus space
"Alexander N. Kabaev" wrote: uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 9 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller at device 7.3 on pci0 intpm0: Could not allocate Bus space Take a look in intpm(4) under the bugs section: This device requires IRQ 9 exclusively. To use this, you should enable ACPI function in BIOS configuration, or PnP mechanism assigns conflicted IRQ for PnP ISA card. And don't use IRQ 9 for Non-PnP ISA cards. Your USB bus controller being on irq 9 might be causing this problem.. Have a play around with IRQ's. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: A record?
Mark Newton wrote: A similar box which I rebooted (for an upgrade from 2.2.5 to 3.2) about a fortnight ago: 3:38PM up 471 days, 5:59, 1 user, load averages: 0.00, 0.02, 0.00 ... and, before this thread gets completely out of control, I direct posters to http://uptime.viper.net.au (warning: if you're easily offended, don't bother). Using options HZ (without a value) you can make any system run as fast as it can, one p100 was elapsing days in 20 minutes.. i had its uptime around 1100days in about 2 weeks.. so nerr my dick is bigger than yours ;) P.S nothing BAD happened over the year 2000 ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone running CompuPic?
I get the same problem, after brandelfing to linux and running it, the splash screen comes up and...disappears with: compupic: abnormal termination: (null) Brandelf -t FreeBSD segfaults it without even showing the splash screen. Nice helpful error message.. can anyone shed some light on that? Tom Embt wrote: Unfortunately, I haven't been able to get it to run. I'm not in FreeBSD right now so I'm working from memory, but I had some trouble with the install process (it is obviously not as portable as they'd have you believe). I seem to recall setting $UID and installing bash, but the script still bombed after it was installed. Then I had to brandelf it. I tried both "Linux" and "FreeBSD" branding and one was working better than the other though I don't recall which. End result: It starts to load, brings up a splash screen, and exits. I do recall it leaving messages on the console but forget which signal it was dying with. I can get more info if it's wanted but first I'm just asking if anyone else has either had better luck than I. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compupic - yes, it works.
YOU DA MAN.. that works fine on -current also "Gray, David W." wrote: MOVE YOUR /usr/compat DIRECTORY aside - rename it temporarily. Run compupic once. You should now be able to move /usr/compat back into place (or /compat, if you left it there...) Why? I dunno. Found it by accident. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NewPCM and Quake :)
I also get this, on an SB32-PNP, with the pcm0 device (setup for pnp) I havnt tried q3atest on the sb0 stuff though.. I might do this weekend. Daniel O'Connor wrote: Hi, I am trying NewPCM on -current with an AWE64. It works fine for normal sound apps like esd, splay etc etc.. but Quake 1 2 which use the DMA buffers to play their sound. It is allowed to do this (the ioctl is supported), but it stutters very badly. Its a bit hard to explain :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: request for review: move of /var/cron/log to /var/log/cron.log
Doug wrote: Nick Hibma wrote: Please review the following patch to get all the log files in one place. The commit will be accompanied by a HEADS UP. If no one objects I will commit this in a couple of days. The only thing I don't like about this is that it introduces a point of incompatibility between FreeBSD and other unices, and I'm not sure the benefit is worth it. I would bring up the idea of creating a symlink in /var/log, but I know that the purists would never approve of that... Whats wrong with FreeBSD going to the fore as far as common sense goes? Are there standards that specify the location of cron's logs? So why not.. maybe other unices will do the same when they see FreeBSD doing it :D mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: followup to apm problems.
Mitsuru IWASAKI wrote: OK. Probably `slept 00:00:00 - 00:00:40' problem was caused by PS/2 mouse, I think. Do we need something to do with psm on suspending as well as resuming? Im not sure anything needs to be done for PS/2.. check out these results.. ed1: NE2000 PCI Ethernet (RealTek 8029) irq 3 at device 9.0 on pci0 Ahh, I meant just unplug cable tentatively to confirm. # and uninstall NIC if possible :) After the problem analyzed, we just try to fix it in proper place. Unplugged NIC, not diabled: Standby: Aug 29 18:33:44 pyros /kernel.old: APM ioctl: cmd = 0x2000500c Aug 29 18:36:28 pyros /kernel.old: Received APM Event: PMEV_STANDBYRESUME Aug 29 18:36:28 pyros /kernel.old: Execute APM hook "default resume." Aug 29 18:36:28 pyros /kernel.old: resumed from suspended mode (slept 00:02:42) Aug 29 18:36:28 pyros /kernel.old: Execute APM hook "PS/2 mouse." Aug 29 18:36:28 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:36:28 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:36:28 pyros apmd[355]: apmevent 000b index 3 Aug 29 18:36:28 pyros apmd: resumed at 19990829 18:36:28 Aug 29 18:36:28 pyros /kernel.old: APM ioctl: cmd = 0x40284164 And i pressed a key because i couldnt be biffed waiting any longer :) So it seems to be working properly! (Yes i am running apmd as well) Suspend: Aug 29 18:41:17 pyros /kernel.old: APM ioctl: cmd = 0x20005001 Aug 29 18:42:33 pyros /kernel.old: Execute APM hook "default suspend." Aug 29 18:42:33 pyros /kernel.old: Received APM Event: PMEV_NORMRESUME Aug 29 18:42:33 pyros /kernel.old: Execute APM hook "default resume." Aug 29 18:42:33 pyros /kernel.old: resumed from suspended mode (slept 00:01:15) Aug 29 18:42:33 pyros /kernel.old: Execute APM hook "PS/2 mouse." Aug 29 18:42:33 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:42:33 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Aug 29 18:42:33 pyros apmd[355]: apmevent 0003 index 5 Aug 29 18:42:33 pyros apmd: resumed at 19990829 18:42:33 Aug 29 18:42:33 pyros /kernel.old: APM ioctl: cmd = 0x40284164 Same deal, I resumed it manually - so it seems to be working also. At least, apm is in /usr/sbin/, apm -z touches /dev/apm and apmd writes log on /var/log/ via syslog :) Using `sysctl -w machdep.apm_suspend_delay=30 (or enough time for spinning down)' and moving `camcontrol stop' to the end of command list would be success. Otherwise, please forgive me. :) I tried that and the drive spins down, and right about 5 seconds before the 30 seconds is up, it spins back up again by itself, then it goes into suspend, but then comes right back out (presumably because of the disk activity). P.S plugging it back in, i do notice it resumes whenever there is activity on the hub :D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: followup to apm problems.
Kazutaka YOKOTA wrote: The PS/2 mouse generates interrupt when /dev/psm0 is open and the user moves the mouse. If you are running moused or X when you suspend the system, /dev/psm0 is left open and might generate interrupts. I think modern motherboard BIOSes have a setup menu that lists which IRQ will wake up the system. I wonder what if you remove IRQ 12 (PS/2 mouse interrupt) from this list. Disabling it on the BIOS list of timer interrupts stops the movement of the mouse from ejecting you from a Standby or Suspend. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
followup to apm problems.
Ive been following the apm problems and changes in apm threads in hope that I would fix the problems that I too am having. I am using the latest sources for apm, apmconf and apmd, as well as the kernel. (as of 23/8/99, NZST, which is yesterday evening) dmesg is: apm0: APM BIOS on motherboard apm: APM BIOS version 0102 apm: Code16 0xc00f, Data 0xc00fdfa0 apm: Code entry 0x8010, Idling CPU enabled, Management enabled apm: CS_limit=0x, DS_limit=0x apm: Engaged control enabled apm: found APM BIOS v1.2, connected at v1.2 apm: Slow Idling CPU enabled Add hook "default suspend" Add hook "default resume" ---and then later on psm0: PS/2 Mouse irq 12 on atkbdc0 Add hook "PS/2 mouse" after going 'apmconf -e' apm shows: APM version: 1.2 APM Managment: Enabled AC Line status: on-line blah blah stuff about batteries which i dont have - desktop computer Resume timer: disabled Resume on ring indicator: enabled APM Capacities: global standby state global suspend state resume timer from standby resume timer from suspend 'apm -Z' for standby jumps into standby mode for like.. an instant, then comes right back out (while playing mp3) dmesg: APM ioctl: cmd = 0x2000500c Received APM Event: PMEV_STANDBYRESUME Execute APM hook "default resume." resumed from suspended mode (slept 00:00:00) Execute APM hook "PS/2 mouse." 'zzz' or 'apm -z' for suspend jumps into suspend mode, and just the same way, comes right back out (while playing mp3s again) dmesg: APM ioctl: cmd = 0x20005001 Execute APM hook "default suspend." Received APM Event: PMEV_NORMRESUME Execute APM hook "default resume." resumed from suspended mode (slept 00:00:01) Execute APM hook "PS/2 mouse." it should be noted that the cpu fan does turn off momentarily for both of these events, and the mp3 that is playing stops, then starts up again where it left off. Even without playing anything through the sound device, it does the same thing. If i leave the thing on with no activity, while running apmd, it goes into suspend or standby (depending on the timers set in the bios) every now and again, but jumps back out as soon as it does. Also, all the PM timer interrupts are disabled. Motherboard is an Abit BH-6 cheers, mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: help
Tattr wrote: Hi i wonder if you can help me please? my friend has just bought a cam for his pc its a webstar and we are having a problem we have loaded the cd and the cam wont work cos it keeps saying video capture devise missing i have the same cam as he and instakked it the same way i went into my control panel to multiemedia and went to video and under it was ppc2 his does not have anything under his i think we need to download this driver (if thats what it is) can you please tell me where i get it or what to do? As you can tell neither of us know too much about computers. Thanks for any help you can give. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message aye!? Is this someones idea of a joke... im laughing.. honest HANNNG ON... -current mailing list.. windows problem.. H - what kinda mental tard would do that? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird X problem
Tomer Weller wrote: very weird X problem, I can only load an X server if I have a ppp connection upi and running... Xfree86 3.4, -CURRENT(made world today) You might want to check your resolv.conf, having an ip that you cant access in there could be causing some things to load extremely slowly as they have to wait for a query to timeout or something - running ppp obviously lets you access your ISP's name server providing you have resolv.conf setup for that ip - you could always run your own caching only name server for that and chuck the boxes own ip into resolv.conf. Mebe upgrading /etc to be inline with -CURRENT you overwrote a few name resolution related files.. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Amancio Hasty wrote: Any one care to recommend a CD writer for FreeBSD-current since thats typically what I run over here. Well, im using a Sony 948S here, works fine under -CURRENT with GCOMBUST (as a front end to mkisofs, mkhybridfs and cdrecord).. except that GCOMBUST occasionally cant figure out the target, rerunning it seems to get past this minor problem. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
