Re: Nt source licenses...
Garance A Drosehn wrote: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... They can't sue - unless, of course, the code is copied verbatim (and it's not very likely to be, anyway). Otherwise, it shouldn't be any more illegal than reverse engineering the code, and several federal appeals courts have held that it is fair use to reverse engineer a program in order to examine and copy its ideas and any unprotected expression. Dean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: make world croaks in perl ??
Make buildworld fails here with: ===/gnu/usr.bin/perl/perl find: build: No such file or directory find: build: No such file or directory mkdir: lib/auto: File exists *** Error code 1 Please look this one up in the archives. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sys/pci pcisupport.c
#I'm busy recently, and shocked by suddenly new-bus merge #happening (I think, its process is not fair). I was lost my head. #Also, one of stress cause is language barrier. English is hard #for me. It is my weak point. Not a problem; most of us do not speak Japanese. :-) I am looking forward to hearing about newconfig from you folk at USENIX! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
On Sun, 16 May 1999, Dean Lombardo wrote: Garance A Drosehn wrote: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... They can't sue - unless, of course, the code is copied verbatim (and They most definately *CAN* sue. I don't think can't sue is something that applies to the US in any way. it's not very likely to be, anyway). Otherwise, it shouldn't be any more illegal than reverse engineering the code, and several federal appeals courts have held that it is fair use to reverse engineer a program in order to examine and copy its ideas and any unprotected expression. But do we have the money to prove that? And if we do, wouldn't it be spend on better things? Dean Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
On Sat, 15 May 1999, Alfred Perlstein wrote: On Sat, 15 May 1999, Narvi wrote: On Fri, 14 May 1999, Garance A Drosehn wrote: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... It would probably be very unwise for the project to get get the licence. However, considering that we support loadable filesystem modules, somebody adventurous enough can get the licence and write a (separate distributed, possibly even only as binary) module. Downloading a kld module from the net definately does not taint your mind. I'm unsure what the fuss is over, don't we have a kld to read NTFS already? How about writing? Is there really anything special about NT that we NEED to learn that hasn't been done _better_ by Sun, SGI or Digital? :) No, not really. -Alfred Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -current page fault at 0xdeadc0de
fault virtual address = 0xdeadc0de 0xdeadc0de - dead code? :-) Is this address a coincidence or a special crafted one? Regards, Marc To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -current page fault at 0xdeadc0de
In message 199905161034.maa00...@oranje.my.domain, Marc van Woerkom writes: fault virtual address = 0xdeadc0de 0xdeadc0de - dead code? :-) Is this address a coincidence or a special crafted one? This is by intention: cd /sys/kern grep -i deadc0de * kern_malloc.c:#define WEIRD_ADDR0xdeadc0de -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
Narvi wrote: On Sun, 16 May 1999, Dean Lombardo wrote: Garance A Drosehn wrote: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... They can't sue - unless, of course, the code is copied verbatim (and They most definately *CAN* sue. I don't think can't sue is something that applies to the US in any way. OK - perhaps I should rephrase it - they *can* sue, but they are not very likely to do so without good reason. Do you really think that someone at Microsoft is going to compare FreeBSD's (OpenBSD's / NetBSD's / Linux's / etc / etc) implementations of NTFS with their own, with the only intention of discovering that some parts were derived from their code? Even if they did, how would they prove it unless the code was indeed identical to theirs? It's an unwinnable war. But do we have the money to prove that? And considering that we don't, it's even less likely. Dean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
Narvi na...@haldjas.folklore.ee writes: Downloading a kld module from the net definately does not taint your mind. I thought 'tainted from reading source' argument had been shot dead during the USL vs Berkely suit? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Fixed my MAMEd sio problem. Was: Re: Doesn't anyone care about the broken sio ??
Just so you all know (the list included) how I have fixed my silo overflow problem which occurred while running xmame (and after I quit until I restarted the X server) I have found the problem doesn't occur if I remove the following lines from the shell script I use to start xmame: xsetpointer Joystick sleep 1 xsetpointer pointer I was doing those three lines just before starting xmame to get the mouse pointer into the top left hand corner (my script also used vidtune to get the right resolution for each game). Since I have removed those lines it works fine. I can now download to my hearts content whilst playing some ancient game. (I'd like to know an easy way to move the mouse pointer though!) With those lines in the script I had to restart the X-server after using xmame or I'd get continuous silo overflows. FYI, the output of xsetpointer -l is: keyboard [XKeyboard] pointer [XPointer] SWITCH[XExtensionDevice] Joystick [XExtensionDevice] And as you can see from the XF86Config file in the message I'm replying to, I am loading several modules to use XExtension Devices and the PC joystick (which is compiled into my kernel): Load xie.so Load pex5.so Load xf86Jstk.so Matthew Thyer wrote: *** STOP PRESS *** I have just confirmed that restarting the X server is enough to fix the problem. So my apologies to Bruce, -CURRENT and the whole FreeBSD community in general for blaming sio. For the benefit of David Dawes, I'll quickly restate the problem: Running xmame (from the ports collection) causes lots of silo overflows with user mode ppp until I either restart the X server or reboot. This occurs even after I exit xmame. This is all on FreeBSD-CURRENT but has been happenning for months and is not newbus related. Thankyou Brian, you are the first to NOT reproduce the problem. Note that all my recent testing of this has been at 300 MHz so dont jump on me when you see that I normally overclock at 450 MHz. So compare configuration: My X server is XFree86 3.3.3.1 (from ports) and I use the XF86_SVGA server. My video card is an ET6000 Jaton VIDEO-58P with 2.25 MB RAM. I run in 16 bit colour with KDE 1.1.1. I run MAME with sound enabled and I'm NOT using Luigi's PCM driver but rather the old driver (whats it called ??). I have a new ABIT BX6 release 2.0 motherboard (with 16550s I assume). I have an Intel Celeron 300a CPU which I normally run at 450 MHz (using a 100 MHz memory bus speed instead of 66 MHz but when I run it at 300 MHz it doesn't make any difference to this problem). I have PC100 SD RAM with an EPROM. This RAM is rated at 7ns believe it or not. I'd like to be using Soren's ATAPI driver but it doesn't like my CD-ROM drive so I'm using the normal wd driver with flags a0ffa0ff. I'm using a KTX V.90 modem at 115000 baud. I typically get 45333, 46667 or 48000 connections to my ISP. I'm using a Microsoft serial mouse but am not using moused. I do have a PS/2 intellimouse compatible mouse attached but only use it when I'm on the darkside (In Windows 95) as it doesn't work with moused or in XFree86. My whole system has been re-compiled within the last 2 days (world, updated /etc, kernel AND ALL ports [XFree86 3.3.3.1, kde 1.1.1 etc etc etc]) Kernel config file (MATTE), /etc/XF86Config file and dmesg output attached. I have one question about my kernel config: How do I know when it's unsafe to use options CPU_DISABLE_5X86_LSSER ? It would be good if the kernel disabled this option under those cases. My /etc/ppp/ppp.conf is: default: set log chat connect phase set device /dev/cuaa1 set speed 115200 allow users matt deny lqr deny chap set timeout 0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ ATX4S95=47 OK-AT-OK \\dATDT\\T TIMEOUT 80 CONNECT set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 isp: set phone ISPNUMBER set login TIMEOUT 10 sername:--sername: MYUSER ssword: MYPASS dial Brian Feldman wrote: On Sat, 8 May 1999, Jordan K. Hubbard wrote: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. Hmm, so now you're the second to cite the possibility of X masking interrupts too long, eh? ;) Actually, I use MAME all the time, and this problem does NOT occur (XF86_SVGA on an S3 ViRGE/DX). Oh, user-ppp too of course. If I could have
Re: No sound (Ensoniq Audio PCI 1370)
On Sat, 15 May 1999, Marc van Woerkom wrote: Dear people, I get no sound anymore using the system built on Friday. As I saw same earlier reports here about problems with sound that were reported to be fixed, mine might be related to the card being a PCI one - ES1370 based genuine Ensoniq Audio PCI. Below follow dmesg output and kernel configuration. device pcm0 at isa? port ? irq 10 drq 1 flags 0x0 I have this: device pcm0 at nexus? port ? irq 10 drq 1 flags 0x0 ^^ Leif Neland To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Different SCSI probe behavior
Every time I boot my -CURRENT system at work I get this problem. And for me its not recent, its been happening ever since the aha driver was finally converted to CAM I think (3 or 4 months I guess). I am using a 1542B with an old Wren drive and some other drive. (Wren 7G springs to mind but I cant be sure). A 1.5GB and a 1.8GB drive are all I have on the SCSI bus. I haven't mentioned it because it still works OK after the 30 or so second delay and I'm too busy at work to provide enough information and follow an email exchange (as I'm not on the lists at work anymore). Khetan Gajjar wrote: On Sat, 15 May 1999, Bret A. Ford wrote: Waiting 10 seconds for SCSI devices to settle aha0: ahafetchtransinfo - Inquire Setup Info Failed (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out aha0: No longer in timeout I'm seeing the same thing, but for 3 of my devices on a chain with 4 devices. It takes quite long, but doesn't appear to do any damage or decrease functionality (so far that is). Do I need to update something for normal behavior? I've been following freebsd-current and cvs-all, though I might have missed something that would have clued me in. I've seen Werner Losch discovering a problem with the aha driver in -stable, and he committed a fix for that. Is it possible for that fix to be MFS ? --- Khetan Gajjar (!kg1779) * khe...@iafrica.com ; khe...@os.org.za http://www.os.org.za/~khetan * Talk/Finger khe...@chain.freebsd.os.org.za FreeBSD enthusiast* http://www2.za.freebsd.org/ Security-wise, NT is a OS with a kick me sign taped to it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
MFS still hosed
With todays -current, mounting /tmp using swap /tmp mfs rw,nosuid,nodev,-s=32768 0 0 yields a Fatal trap 12: page fault while in kernel mode fault virtual address= 0x9d203590 fault code = supervisor read, page not present instruction pointer = 0x8:0xc016f30c stack pointer= 0x10:0xc5aa2d70 frame pointer= 0x10:0xc5aa2d9c code segment = base 0x0, limit 0x, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 362 (mount_mfs) Stopped at checkalias+0x13c: movl cdevsw(%eax),%eax %eax contains 0xdcfba6d0 This line in checkalias() in vfs_subr.c seems to be the culprit: 1488: 56 pushl %esi 1489: e8 fc ff ff ff call 148a checkalias+0x12e 148e: 8b 04 85 00 00 movl 0x0(,%eax,4),%eax 1493: 00 00 1495: c1 e0 02shll $0x2,%eax = 1498: 8b 80 00 00 00 movl 0x0(%eax),%eax 149d: 00 149e: 89 45 e4movl %eax,0xffe4(%ebp) (I'm not sure yet which source line this section corresponds to :-) Anyone else seen this? -- Jos Backus _/ _/_/_/ Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Different SCSI probe behavior
In message pine.bsf.4.02a.9905152126520.5171-100...@pleb.cs.uct.ac.za Khetan Gajjar writes: : On Sat, 15 May 1999, Bret A. Ford wrote: : : Waiting 10 seconds for SCSI devices to settle : aha0: ahafetchtransinfo - Inquire Setup Info Failed : (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out : (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out : aha0: No longer in timeout : : I'm seeing the same thing, but for 3 of my : devices on a chain with 4 devices. It takes quite long, : but doesn't appear to do any damage or decrease functionality : (so far that is). : : Do I need to update something for normal behavior? I've been following : freebsd-current and cvs-all, though I might have missed something : that would have clued me in. : : I've seen Werner Losch discovering a problem with the aha : driver in -stable, and he committed a fix for that. : Is it possible for that fix to be MFS ? Ahem, it is Warner Losh :-). There was a problem in -stable (and likely -current) for some aha cards. The ahafetchtransinfo routine is called at probe time, so if there are timeouts there and no where else they can be safely ignored, even if it is an irritation. I commited fixes to both -stable and -current for this problem, so you might want to try post a May 14 kernel. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Different SCSI probe behavior
In message 199905151840.laa00...@uop.cs.uop.edu Bret A. Ford writes: :This morning, I did an installworld and booted a new -current : world and -current kernel (Sources from morning of Fri May 14th). : I got the following messages during the SCSI probe: : : Waiting 10 seconds for SCSI devices to settle : aha0: ahafetchtransinfo - Inquire Setup Info Failed : (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out : (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out : aha0: No longer in timeout : :I'm not sure what to make of this. After a bit of a delay - 30 or : so seconds, I don't quite recall how long - the system continued : booting, normally the rest of the way, and seems to be functional. : Do I need to update something for normal behavior? I've been following : freebsd-current and cvs-all, though I might have missed something : that would have clued me in. I've fixed this late Friday. You need aha.c 1.25 or newer in order to correct this problem. : ahc0: Adaptec 274X SCSI host adapter at slot 4 on eisa0 : ahc0: aic7770 = Rev E, Wide Channel A, SCSI Id=7, 4/255 SCBs : aha0 at ports 0x130-0x133 and 0x131-0x134 irq 11 drq 7 on isa0 : aha0: AHA-1542C FW Rev. 0.1 (ID=44) SCSI Host Adapter, SCSI ID 7, 16 CCBs Intesting. My 1542C didn't show this behavior, but I have put the workaround in... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Different SCSI probe behavior
In message 373ef0b7.60fe8...@camtech.com.au Matthew Thyer writes: : Every time I boot my -CURRENT system at work I get this problem. : And for me its not recent, its been happening ever since the aha : driver was finally converted to CAM I think (3 or 4 months I guess). : : I am using a 1542B with an old Wren drive and some other drive. : (Wren 7G springs to mind but I cant be sure). A 1.5GB and a 1.8GB : drive are all I have on the SCSI bus. : : I haven't mentioned it because it still works OK after the 30 or : so second delay and I'm too busy at work to provide enough : information and follow an email exchange (as I'm not on the lists : at work anymore). Please try the latest aha driver. Please do let me know if you see this on your machine at boot, as I've not seen it on mine. I'll do more testing of different aha cards shortly... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
KDE-1.1.1
With a current as of yesterday morning, I just tried to upgrade to KDE-1.1.1 through ports kde11 and had the problem with libstdc++.so.3 and libstdc++.so.2 conflicts. Does anyone know an easy workaround? It seems to show up throught the kde package. Thanks, ed To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
Hi, At 15:22 11/05/99 -0700, you wrote: Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. If anybody else needs it, please let me know and I'll see what I can do for you. I'm going to have a use for it RSN It doesn't work. Don't use it. You need to reboot the system to restore various vectors that DOS destroys. Please see the previous threads on this topic, especially anything from Robert Nordier. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: MFS still hosed
On Sun, 16 May 1999, Jos Backus wrote: With todays -current, mounting /tmp using swap /tmp mfs rw,nosuid,nodev,-s=32768 0 0 yields a Fatal trap 12: page fault while in kernel mode fault virtual address= 0x9d203590 I've been getting this for a week now. :( Luoqui Chen suggested bumping NUMCDEV in src/sys/kern/kern_conf.c to 255 to get around it, and a couple of people had success, including myself. I've filed PR kern/11737 with the fix. Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
sys/types.h rev. 1.33 breaks ps etc. on alpha
Revision 1.33 of src/sys/types.h, which changed dev_t to a void * in the kernel, breaks ps and a bunch of other things on the alpha. Since dev_t now has a different size in the kernel than in userland, ps and friends get a proc size mismatch. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
On Sun, 16 May 1999, Mike Smith wrote: Hi, At 15:22 11/05/99 -0700, you wrote: Because I need it, I have upgraded fbsdboot.exe so now it can recognize ELF. If anybody else needs it, please let me know and I'll see what I can do for you. I'm going to have a use for it RSN It doesn't work. Don't use it. You need to reboot the system to restore various vectors that DOS destroys. Please see the previous threads on this topic, especially anything from Robert Nordier. Well, it works for me. The only problem is that fbsdboot never returns, allowing win98 to clean up. Therefore win98 tries to start my dos program on each boot. Luckily I have C: accessible as /c, so I could edit autoexec.bat and config.sys Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: MFS still hosed
On Sun, May 16, 1999 at 01:36:44PM -0700, Doug White wrote: I've been getting this for a week now. :( Luoqui Chen suggested bumping NUMCDEV in src/sys/kern/kern_conf.c to 255 to get around it, and a couple of people had success, including myself. I'll do that then. Thanks! Groetjes, -- Jos Backus _/ _/_/_/ Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Nt source licenses...
Dean Lombardo writes: At 3:51 PM +0700 5/12/99, Ustimenko Semen wrote: Are we going to get this license? I am interested in NTFS source code a lot... I would be very careful about getting an NT source license if your intention is to write NTFS support for some other operating system. Microsoft is not doing this licensing for the benefit of mankind, they are doing it to attract college-type users to sticking with WinNT over open-source unixes. The last thing we need is some code from WinNT which causes us to be sued by Microsoft... They can't sue - unless, of course, the code is copied verbatim (and it's not very likely to be, anyway). Otherwise, it shouldn't be any more illegal than reverse engineering the code, and several federal appeals courts have held that it is fair use to reverse engineer a program in order to examine and copy its ideas and any unprotected expression. You're forgetting about possible patent violations... -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
It doesn't work. Don't use it. You need to reboot the system to restore various vectors that DOS destroys. Please see the previous threads on this topic, especially anything from Robert Nordier. The most relevant piece I can find from R. Nordier is the following: The fbsdboot.exe program should probably be considered obsolete. It should (in theory) be possible to use it to load /boot/loader, which can then load the kernel, but there are various reasons this doesn't work too well. I have not tested the updated program with /boot/loader. /boot/loader does not help me because my root directory is in a memory file system, and I can not assume that my users will want to reformat their DOS drives or even repartition it. So all FreeBSD files are in the DOS file system. --Carlos To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
rplayd: mixer not installed
At boot I get this message: /usr/local/sbin/rplayd: rplay_audio_get_volume: pcm mixer device not installed. However, /dev/mixer is installed, and works. I'm using current, Luiqi's pcm and a ESS soundcard. Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Fixed my MAMEd sio problem. Was: Re: Doesn't anyone care about the broken sio ??
Just so you all know (the list included) how I have fixed my silo overflow problem which occurred while running xmame (and after I quit until I restarted the X server) I have found the problem doesn't occur if I remove the following lines from the shell script I use to start xmame: xsetpointer Joystick sleep 1 xsetpointer pointer FreeBSD's joystick driver certainly causes silo overflows. It disables CPU interrupts and polls for 2 msec. For 16550 serial hardware, this may cause loss of 21 characters at 115200 bps (23 characters arriving in 2 msec less 2 characters of buffering provided by the 16550 fifo above the trigger level). If sio used a more conservative trigger level of 8, then then the loss would be limited to only 15 characters. With those lines in the script I had to restart the X-server after using xmame or I'd get continuous silo overflows. Closing the joystick device should also work. The joystick driver shouldn't disable CPU interrupts or mask clock interrupts. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Building ports...
Heya... I apologize if this is a slight off topic question, but I think it might be related to -current... Just loaded a 3.1-STABLE box, and went to build a couple of ports. First it told me that I couldn't use the bsd.port.mk because it was too old. Fine, so I go and cvsup the current sources for /usr/share, and I do a make install in /usr/src/share/mk. The files install properly, and I go to the ports collection. I go into a number of ports, and try a 'make' an any given port. It then tells me the following: fetch: illegal option -- A So, it can't go out and grab the needed files to build the port. No big deal, I just go grab the source and make it manually. This is not a huge problem, but I'm just wondering what I've done wrong, or what I'm stupidly forgetting to add or do additionally... Any feedback would be great, TIA!!! __ -Gary Margiotta Voice: (973) 835-7855 TBE Internet Services Fax:(973) 835-4755 http://www.tbe.net E-Mail: g...@tbe.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
It doesn't work. Don't use it. You need to reboot the system to restore various vectors that DOS destroys. Please see the previous threads on this topic, especially anything from Robert Nordier. The most relevant piece I can find from R. Nordier is the following: The fbsdboot.exe program should probably be considered obsolete. It should (in theory) be possible to use it to load /boot/loader, which can then load the kernel, but there are various reasons this doesn't work too well. These reasons were also expounded, and I did summarise them in another message on this thread. I have not tested the updated program with /boot/loader. /boot/loader does not help me because my root directory is in a memory file system, and I can not assume that my users will want to reformat their DOS drives or even repartition it. So all FreeBSD files are in the DOS file system. The loader won't help you because you are booting from under DOS, but the loader will boot the kernel just fine off a DOS filesystem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
zzz crashing in current OR inthand_remove not removing handlers properly
Hi, on a -current from around a week ago `zzz' always managed to crash
my machine. The relevant parts from the panic and the backtrace are
included below.
It seems that the cause of this was a stray interrupt was arriving
after having unloaded the driver. For some reason it wasn't handled
by isa_strayintr, and the reason for that was that inthand_remove
didn't manage to remove the interrupt (and get it replaced by the
stray function) correctly. After applying the patch at the end of
this mail I can once again sleep my laptop succesfully.
/assar
--
from dmesg:
ep0: utp/bnc[*UTP*] address 00:a0:24:af:cc:7e
APM ioctl: cmd = 0x20005001
DEVICE_SUSPEND error 6, ignored
Execute APM hook pcm suspend handler.
Called APM sound suspend hook for unit 0
Execute APM hook Cirrus Logic PD672X.
Execute APM hook Cirrus Logic PD672X.
ep0: unload
Return IRQ=11
from the panic:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0256ff3
stack pointer = 0x10:0xc39a6cdc
frame pointer = 0x10:0xc39a6ce4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 951 (zzz)
interrupt mask = net tty
and the backtrace:
#9 0xc02020ef in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = -2147483648, tf_ebp = -1013289756, tf_isp = -1013289784,
tf_ebx = -1068408832, tf_edx = -1071675062, tf_ecx = 10,
tf_eax = -1071288448, tf_trapno = 12, tf_err = 2, tf_eip = -1071288333,
tf_cs = 8, tf_eflags = 68103, tf_esp = -1071576167, tf_ss = -559038242})
at ../../i386/i386/trap.c:436
#10 0xc0256ff3 in M_TEMP ()
#11 0xc02106ce in splx (ipl=3223270597) at ../../i386/isa/ipl_funcs.c:106
#12 0xc01f34c5 in apm_execute_hook (list=0xc0511c00)
at ../../i386/apm/apm.c:351
#13 0xc01f3650 in apm_suspend (state=2) at ../../i386/apm/apm.c:466
#14 0xc01f3f98 in apmioctl (dev=9984, cmd=536891393, addr=0xc39a6edc ,
flag=3, p=0xc3639520) at ../../i386/apm/apm.c:991
#15 0xc0165fae in spec_ioctl (ap=0xc39a6e18)
at ../../miscfs/specfs/spec_vnops.c:440
#16 0xc0165839 in spec_vnoperate (ap=0xc39a6e18)
at ../../miscfs/specfs/spec_vnops.c:129
#17 0xc01d8ebd in ufs_vnoperatespec (ap=0xc39a6e18)
at ../../ufs/ufs/ufs_vnops.c:2327
#18 0xc015d0b5 in vn_ioctl (fp=0xc08ab680, com=536891393, data=0xc39a6edc ,
p=0xc3639520) at vnode_if.h:395
#19 0xc013f1b7 in ioctl (p=0xc3639520, uap=0xc39a6f90)
at ../../kern/sys_generic.c:564
#20 0xc0202a56 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 3, tf_esi = -1077944864, tf_ebp = -1077945212,
tf_isp = -1013288988, tf_ebx = 0, tf_edx = -1077944868, tf_ecx = 0,
tf_eax = 54, tf_trapno = 7, tf_err = 2, tf_eip = 671703256, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077945228, tf_ss = 47})
at ../../i386/i386/trap.c:1066
#21 0xc01f79b0 in Xint0x80_syscall ()
--
Index: sys/i386/isa/intr_machdep.c
===
RCS file: /src/fbsd-repository/src/sys/i386/isa/intr_machdep.c,v
retrieving revision 1.21
diff -u -w -u -w -r1.21 intr_machdep.c
--- intr_machdep.c 1999/05/04 21:18:20 1.21
+++ intr_machdep.c 1999/05/17 02:15:18
@@ -823,12 +823,11 @@
oldspl = splq(1 irq);
- /* we want to remove the list head, which was known to intr_mux
*/
- icu_unset(irq, intr_mux);
/* check whether the new list head is the only element on list
*/
head = intreclist_head[irq];
if (head != NULL) {
+ icu_unset(irq, intr_mux);
if (head-next != NULL) {
/* install the multiplex handler with new list
head as argument */
errcode = icu_setup(irq, intr_mux, head, 0, 0);
@@ -842,6 +841,8 @@
if (errcode == 0)
update_intrname(irq, head-name);
}
+ } else {
+ icu_unset(irq, idesc-handler);
}
splx(oldspl);
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: FBSDBOOT.EXE
The loader won't help you because you are booting from under DOS, but the loader will boot the kernel just fine off a DOS filesystem. I'd like to understand this aspect of the loader better. This mode might be useful for booting from (for example) a DOS flash filesystem? Um... off to the source code. Thanks for the tip. Cheers, Jerry Hicks wghi...@bellsouth.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Different SCSI probe behavior
Interesting that this should come up. I'm getting timeouts also, but not on aha. (da1:bt0:0:1:0): CCB 0xc549d680 - timed out bt0: No longer in timeout (sa0:bt0:0:3:0): READ(06). CDB: 8 0 0 28 0 0 (sa0:bt0:0:3:0): UNIT ATTENTION asc:29,0 (sa0:bt0:0:3:0): Power on, reset, or bus device reset occurred (da1:bt0:0:1:0): CCB 0xc549ccc0 - timed out bt0: No longer in timeout (sa0:bt0:0:3:0): WRITE(06). CDB: a 0 0 28 0 0 (sa0:bt0:0:3:0): UNIT ATTENTION asc:29,0 (sa0:bt0:0:3:0): Power on, reset, or bus device reset occurred It seems that if I have tings happening on both a hard disk and the tape drive, I get these kinds of timeouts. I just tried to do a backup with tar cvb 20 / /usr and it died after 3 or so blocks with: Device not configured. I can read those blocks back off the tape, just fine. The tape drive was working before cam, but I was out of the country and offline March and April, so I don't entirely know when it stopped. I am running stable as of Sunday morning. Note: this is an ASUS-P2B-DS, the Adaptec controller is on the mother board, but won't handle more than a couple fast-scsi devices. I've got 4. So I'm still using my old Buslogic board, that all the scsi-2 devices were connected to and working fine before the new motherboard. Ideas? Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.2-STABLE #2: Sun May 16 00:13:44 EDT 1999 dzer...@zoomer:/usr/src/sys/compile/zoomer Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping=2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,MMX,b24 real memory = 134217728 (131072K bytes) avail memory = 127467520 (124480K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc02e9000. Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.4.0 chip3: Intel 82371AB Power management controller rev 0x02 on pci0.4.3 ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs bt0: Buslogic Multi-Master SCSI Host Adapter rev 0x00 int b irq 16 on pci0.9.0 bt0: BT-946C FW Rev. 4.24 Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs xl0: 3Com 3c905B-TX Fast Etherlink XL rev 0x64 int a irq 18 on pci0.10.0 xl0: Ethernet address: 00:50:04:60:70:70 xl0: autoneg complete, link status good (half-duplex, 10Mbps) fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 17 on pci0.11 .0 fxp0: Ethernet address 00:a0:c9:e5:00:19 Probing for devices on PCI bus 1: vga0: Matrox model 0521 graphics accelerator rev 0x01 int a irq 16 on pci1.0.0 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 4 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 flags 0x10 on isa sio1: type 16550A pca0 on motherboard pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Checking for GUS Plug-n-Play ... No Plug-n-Play devices were found gus0 at 0x220 irq 11 drq 1 flags 0x105 on isa snd0: GUS PNP (CS4231A) snd0: Gravis PNP (512k) apm0 on isa apm: found APM BIOS version 1.2 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 SMP: AP CPU #1 Launched! sa0 at bt0 bus 0 target 3 lun 0 sa0: HP HP35470A 1109 Removable Sequential Access SCSI-2 device bt0: bt_cmd: Timeout waiting for command (d) to complete. bt0: status = 0x10, intstat = 0x81, rlen 33 bt0: btfetchtransinfo - Inquire Setup Info Failed 3c sa0: 3.300MB/s transfers da1 at bt0 bus 0 target 1 lun 0 da1: Quantum VP32170 L912 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2069MB (4238640 512 byte sectors: 255H 63S/T 263C) da2 at bt0 bus 0 target 2 lun 0 da2: IBM DORS-32160 S82C Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da0 at ahc0 bus 0 target 0 lun 0 da0: IBM DDRS-34560D DC1B Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) changing root device to da0s2a cd0 at bt0 bus 0 target 4 lun 0 cd0: PLEXTOR
pccard status?
I installed the April 13 -current snap on my laptop, but I can't build a kernel that will run pccards. pcic fails to allocate an IRQ, and the kernel module pcic won't load. I thought April 13 would avoid the newbus problems, but apparently there were problems back then too. A kernel build with -current sources from March 14 or so works, but has other problems (can't run top, ps, w). I tried using /usr/src/sys/pccard from March 14, but this makes no difference. Is there anything I might try to fix this, other than installing an earlier version? Annelise To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: zzz crashing in current OR inthand_remove not removing handlers properly
On Mon, May 17, 1999 at 04:33:12AM +0200, Assar Westerlund wrote: Hi, on a -current from around a week ago `zzz' always managed to crash my machine. The relevant parts from the panic and the backtrace are included below. It seems that the cause of this was a stray interrupt was arriving after having unloaded the driver. For some reason it wasn't handled by isa_strayintr, and the reason for that was that inthand_remove didn't manage to remove the interrupt (and get it replaced by the stray function) correctly. After applying the patch at the end of this mail I can once again sleep my laptop succesfully. Wow. I think that's actually done the trick. Not only can I suspend, but I can now remove my 3C589 without a panic. ... well, I just managed to lock up the machine.. but I think that was from a missed remove event. I must have lost that polling patch somewhere along the way. -- Christopher Masto Senior Network Monkey NetMonger Communications ch...@netmonger.neti...@netmonger.nethttp://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
