Re: DVD-ram
crypt0genic [EMAIL PROTECTED] writes: I have a Lacie DVD-RAM drive, it work great under windows, here is the DMESG i g et from it, I hope this is of some help. LaCie don't make drives, they just package them in ugly boxes with noisy fans. One of my cow-orkers (with whom I share an office) had an external LaCie disk hooked up to his Mac until I threatened to pour Coca Cola into the PSU (this was after I'd hinted several times that the handles on his G3 would serve very well for chucking it out the window) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DVD-ram
* Dag-Erling Smorgrav ([EMAIL PROTECTED]) [990701 11:47]: LaCie don't make drives, they just package them in ugly boxes with noisy fans. Im not sure what model you are refering too, but the drive I have is in a stylish external box with a fan that doesnt make a whisper on noise, It also doesnt make any sound when reading/writeing. The unit is so sturdy I rekon I could through it at a brick wall without damaging it! Overall Im very pleased with this piece of hardware and when it is supported under freebsd it will be one of my most prised devices. : ) -crypt0genic -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website:http://www.ecad.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DVD-ram
crypt0genic [EMAIL PROTECTED] writes: * Dag-Erling Smorgrav ([EMAIL PROTECTED]) [990701 11:47]: LaCie don't make drives, they just package them in ugly boxes with noisy fans. Im not sure what model you are refering too, but the drive I have is in a stylish external box with a fan that doesnt make a whisper on noise, It also doesnt make any sound when reading/writeing. The unit is so sturdy I rekon I could through it at a brick wall without damaging it! Overall Im very pleased with this piece of hardware and when it is supported under freebsd it will be one of my most prised devices. : ) The box may look solid, but the drive inside is a standard OEM component (Matshita, IIRC) which would certainly not survive the impact, no matter how sturdy an enclosure it's in - unless the enclosure has internal shock mounts, which would frankly surprise the hell out of me given LaCie's generally low prices. You get what you pay for. And the fan may be nice and silent now, but how do you know that'll last? My cow-orker's unit was two months old when the fan started screaming like a butchered pig. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Postfix license update.
Just to let you all know, it appears that the termination clause has been dropped, but it appears to have gained a gpl-like "must make source available" clause. http://msgs.securepoint.com/cgi-bin/get/postfix9906/103.html (and where I found it) http://www.lwn.net/1999/0701/a/postfix.html -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GRE encapsulation under FreeBSD 3.2
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: On Wed, 30 Jun 1999, Jonathan Lemon was heard blurting out: In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: I don't seem to see support for GRE (IP-in-IP encaspulation) in FreeBSD (although I might be blind)...anyone working on support it or is there already an implementation? Yes, I've grabbed the GRE support from NetBSD, and have it working here (as far as I can tell). I'll commit it in a day or two. -- Jonathan Does this mean NATD/VPN using the -pptpalias will work for the clients that are using M$ VPN? If so, the sooner the better for me. Hmm, I don't know what that is, nor what relation it has to GRE. Do you hve an URL that would enlighten me? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
Reminds me of SCO. I personally don't much like it- it makes it harder than hell to figure out what's gone wrong when it doesn't work. On Thu, 1 Jul 1999, Steve Ames wrote: Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
True... But such a configuration doesn't preclude the use of a more detailed listing on vty1 the way we do it now. With our current installation setup its similar to this already. Its text based and some of the menus are not exactly intuitive (No... I don't have a better suggestion just yet). If something goes wrong you don't really know what unless you look at the second vty (ALT-F2) and then (maybe) there is some good info there. I've had a lot of installs go awry with little information to explain to me what went wrong. Like you, I'd prefer a very primitive interface if it gave me lots more diagnostics. Joe Average, on the other hand, likes a spiffy, clean interface. We try to accomodate both types by having a simplistic install and then some detail output on a seperate VTY. This could still be done with an even spiffier graphical installation on the first VTY. Wonder if it utilizes the VGALIB? (Lizard that is) Reminds me of SCO. I personally don't much like it- it makes it harder than hell to figure out what's gone wrong when it doesn't work. On Thu, 1 Jul 1999, Steve Ames wrote: Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
if it gave me lots more diagnostics. Joe Average, on the other hand, likes a spiffy, clean interface. We try to accomodate both types by having a simplistic install and then some detail output on a seperate VTY. This could still be done with an even spiffier graphical installation on the first VTY. Possibly. It's not clear what or who "Joe Average" is here. I suspect that 99% of all computer users (by volume) get their s/w preinstalled. The amount of sophistication of the remaining 1% who actually struggle through so-called "spiffy" installs is growing exponentially. Keeping a simple interface rather than trying to play human engineering with no real human interfaces lab and a 500K$ testing budget might be better. Just my 2 cents... I'll shut up now... (I mean, why should *I* beef so much? I'm not writing or maintaining sysinst...) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: npx0 to set maxmem broken in -current?
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: Personally, I think we should use a kernel environment variable passed in from loader, since kern_envp is available *real early*, from the very beginning of init386(), which is called form locore just after going virtual. It needs a couple of tweaks to get this to work, and in particular, the environment variable will have to override the VM86 calls. You'd still have to perform the VM86 calls, since one of the things they do is generate a map of where the useable memory segments are. The environment variable would be used later (at the same point where the npx0 hack is) in order to cap Maxmem. I like the idea of being able to say: set console=comconsole set maxmem= boot -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
OK, I'll add a few comments to this. And I'll respond... The actual pros and cons of the current installer and what a new one would look like is not the real question to answer here,... I have to say that what we have isn't that bad- it fails only in some areas where it violates the principle of least surprise. It's quite similar to the Slackware install in that it's simple but does have some fastpath items that work for a large number of cases and it tries to sanity check as it goes. That's really all that's needed for almost all the cases (I assert). I'm really not sure that the Windows-like look is a smart move. I mean, KDE looks like a VGA version of win95 and this was all a clever joke with fvwm95 but it's wearing thin. What actual marketing information do we actually have that says that in order to go after the desktops we aren't currently installed on we have to add a lot of engineering effort to the installer? Would it be better to try and work some deals with Compaq or Dell (so that they hedge their bets on Linux) and be a preinstalled choice for those systems instead of trying go after the (exceedingly rare and getting rarer) desktop user who actually installs an entire OS from CD? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
What actual marketing information do we actually have that says that in order to go after the desktops we aren't currently installed on we have to add a lot of engineering effort to the installer? Would it be better to Well, just to clear up what looks like a misunderstanding in the making, let me say that the engineering effort we're contemplating here has nothing to do with going after the desktop, it has to do with better security, better componentization(?) of the OS and 3rd party apps, better upgrades, better underlying technology basically. :) - JOrdan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
My bad, as the current generation says, and it's a major item on my TODO list to spend about 2 days pouring through his code and generating a comprehensive set of comments about where to go from there. Unfortunately, this code is also in the very early stages and represents about 34,000 lines of uncommented C++ and TCL code which requires egcs, turbovision 0.7 and (optionally) Qt 1.42 to build so the learning/testing curve is a bit steep. Every person I've handed a copy to so far has never reported back with anything to pass on to the contractor in question.. :) Would it be possible to have this code put up for www/ftp or something, so that anyone who is interested could have a look? I, for one, would like to have a look at it. Nathan, not ready to commit to working on something like this. :( -- Nathan AhlstromFreeBSD: http://www.FreeBSD.org/ [EMAIL PROTECTED] PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard problems
Indeed. Is it possibly interrupting on a line which something else is using? I've found a problem on my Latitude where it appears that the machine only has two interrupts free (3 and 9). If I put a modem on 3 and an Ethernet board on 9, it works, but only by putting pccardd on irq 5, which doesn't really work. If I pull the Ethernet card, the whole machine hangs up when I try to access the net, presumably because pccardd hasn't found out about it. Have you tried setting the PCIC IRQ to 0, so that the driver polls instead? -- \\ 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-hackers" in the body of the message
Xfree86 v 3.3.4
Does anyone have any inside information on subj? The website still claims: "We are planning to release 3.3.4 some time in June 1999" I'm longing to get support for my S3 Trio3D. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... Show us how to a) script it, and b) make it run on a serial terminal, and you'll get a lot more of peoples' attention. 8) -- \\ 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-hackers" in the body of the message
Re: Lizard...
Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... Show us how to a) script it, and b) make it run on a serial terminal, and you'll get a lot more of peoples' attention. 8) *grin* Always the trick isn't it? I think Jordan pointed out all of the good stuff on this topic. Its pretty obvious that one install isn't going to meet everyone's need. FreeBSD does not focus on the desktop and so doesn't need a desktop oriented install. It has also been pointed out that most people don't install their own OS anway unless they have some semblence of technical knowledge or daring. These people don't need a hold-your-hand type install. That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: "You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) -Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lizard...
That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: "You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: npx0 to set maxmem broken in -current?
Personally, I think we should use a kernel environment variable passed in from loader, since kern_envp is available *real early*, from the very beginning of init386(), which is called form locore just after going virtual. It needs a couple of tweaks to get this to work, and in particular, the environment variable will have to override the VM86 calls. It shouldn't "override it", rather it should simply lower the current 4GB cap to whatever it's set to. This allows the BIOS sensing code to correctly walk around holes, etc. -- \\ 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-hackers" in the body of the message
Re: Lizard...
That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: "You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. I'd have to concur. I've done both - actually - the RedHat really isn't that different from FreeBSD (that was RedHat 5.2.) - a few of nice boxes you fill in - pop the CD in the drive... *poof* - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Xfree86 v 3.3.4
There is a Linux X server for the Voodoo Banshee, over at: http://developer.soundblaster.com/linux/ You might have some luck running it under the Linux emulator. I've never tried it, as I don't have a Banshee. -Mark Taylor NetMAX Developer [EMAIL PROTECTED] http://www.netmax.com/ On 01-Jul-99 David Scheidt wrote: On Thu, 1 Jul 1999, Leif Neland wrote: Does anyone have any inside information on subj? The website still claims: "We are planning to release 3.3.4 some time in June 1999" I'm longing to get support for my S3 Trio3D. Heh. It now says early july. I have a Voodoo Banshee I want to use. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
reason for slow user-user memory copy
A graduate student here implements a mmap() interface to a TCP/IP network card. He notices that it takes much longer time to copy from mmapp()'ed area to another user area than it takes to copy the same amount of data from kernel space to user space. The students here have no idea why this could be possible. I hope someone on this list can give us a hint. Below is a part of his original email. He uses rdtsc instruction to do the timing. Well I have implemented a memory mapped interface for the user in Linux using the DEC 21140 Tulip ethernet card. Thus the user has access to the buffers, but when I did a memcpy from the RX buffer to the user variable, it took an extraordinary amount of time, approx 70 microsec for 1460 btyes... where as the original scheme takes 25 microsec for the same data when it does a memcpy_to_iovec in tcp_recvmsg(). I am confused by this unexpected timings. More than 80% of the time is spent doing the memcpy. --- Thanks for your help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reason for slow user-user memory copy
hmm Unfortunatly Linux is nt relevent to FreeBSD so we can't comment directly.. it is possible that the mmapped region is marked non-cachable, which migh tmake a difference. I have no idea where "memcpy_to_iovec" in Linux is copying to so it's hard to comment. julian On Thu, 1 Jul 1999, Zhihui Zhang wrote: A graduate student here implements a mmap() interface to a TCP/IP network card. He notices that it takes much longer time to copy from mmapp()'ed area to another user area than it takes to copy the same amount of data from kernel space to user space. The students here have no idea why this could be possible. I hope someone on this list can give us a hint. Below is a part of his original email. He uses rdtsc instruction to do the timing. Well I have implemented a memory mapped interface for the user in Linux using the DEC 21140 Tulip ethernet card. Thus the user has access to the buffers, but when I did a memcpy from the RX buffer to the user variable, it took an extraordinary amount of time, approx 70 microsec for 1460 btyes... where as the original scheme takes 25 microsec for the same data when it does a memcpy_to_iovec in tcp_recvmsg(). I am confused by this unexpected timings. More than 80% of the time is spent doing the memcpy. --- Thanks for your help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reason for slow user-user memory copy
On Thu, 1 Jul 1999, David Greenman wrote: A graduate student here implements a mmap() interface to a TCP/IP network card. He notices that it takes much longer time to copy from mmapp()'ed area to another user area than it takes to copy the same amount of data from kernel space to user space. The students here have no idea why this could be possible. I hope someone on this list can give us a hint. Below is a part of his original email. He uses rdtsc instruction to do the timing. Well I have implemented a memory mapped interface for the user in Linux using the DEC 21140 Tulip ethernet card. Thus the user has access to the buffers, but when I did a memcpy from the RX buffer to the user variable, it took an extraordinary amount of time, approx 70 microsec for 1460 btyes... where as the original scheme takes 25 microsec for the same data when it does a memcpy_to_iovec in tcp_recvmsg(). I am confused by this unexpected timings. More than 80% of the time is spent doing the memcpy. --- If the mapping is being done via a device mapping, then the region will be marked non-cacheable. -DG I remember that he said he created a character device /dev/tulip to represent the network card. Actually, his work borrowed a lot from the Cornell U-Net project (now the basis of VIA?). Can we change the corresponding page table (directory) entries to be cacheable as needed? -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: npx0 to set maxmem broken in -current?
a bit late
you should check teh cvs rep for these files..
peter's already checked it in... :-)
On Thu, 1 Jul 1999, Andrew Gallatin wrote:
Peter Wemm writes:
Peter,
Thanks for the details. I wasn't sure if it was something that was
supposed to work... I assume it still works when built in by config
should be left in place for that reason though, right? (haven't tried
it here..)
Personally, I think we should use a kernel environment variable passed in
from loader, since kern_envp is available *real early*, from the very
beginning of init386(), which is called form locore just after going
virtual. It needs a couple of tweaks to get this to work, and in
particular, the environment variable will have to override the VM86
calls.
Great idea! I'd thought about adding a boot flag, but didn't realize
the kernel environment variable route was so easy.
The following hack seems to work here. At least it should have the
same effect as building with MAXMEM. The only bit that concerns me is
the movement of the movement of the kern_envp initialzation. I don't
know diddly about the early stages of the boot I don't know if
moving it so that environment variables are available in getmemsize()
is safe. Can you take a peek at this patch please?
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.342
diff -u -b -B -c -r1.342 machdep.c
cvs diff: conflicting specifications of output style
*** machdep.c 1999/06/18 14:32:14 1.342
--- machdep.c 1999/07/01 23:28:50
***
*** 153,158
--- 153,164
CTLFLAG_RD, tlb_flush_count, 0, "");
#endif
+ int i386_maxmem=0;
+
+ SYSCTL_INT(_machdep, OID_AUTO, maxmem, CTLFLAG_RD,
+ i386_maxmem, 0, "override memory auto-size at boottime");
+
+
#ifdef PC98
static int ispc98 = 1;
#else
***
*** 1331,1337
/*
* If a specific amount of memory is indicated via the MAXMEM
! * option or the npx0 "msize", then don't do the speculative
* memory probe.
*/
#ifdef MAXMEM
--- 1337,1344
/*
* If a specific amount of memory is indicated via the MAXMEM
! * option or the npx0 "msize", or the machdep.maxmem kernel
! * environment variable, then don't do the speculative
* memory probe.
*/
#ifdef MAXMEM
***
*** 1347,1352
--- 1354,1365
}
}
#endif
+ if (getenv_int("machdep.maxmem", i386_maxmem) != 0) {
+ if(i386_maxmem != 0) {
+ Maxmem = i386_maxmem / 4;
+ speculative_mprobe = FALSE;
+ }
+ }
#ifdef SMP
/* look for the MP hardware - needed for apic addresses */
***
*** 1656,1661
--- 1669,1680
dblfault_tss.tss_ldt = GSEL(GLDT_SEL, SEL_KPL);
vm86_initialize();
+ /*
+ * moved here to make machdep.maxmem available in
+ * getmemsize. Not sure if this is safe
+ */
+ if (bootinfo.bi_envp)
+ kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
getmemsize(first);
/* now running on new page tables, configured,and u/iom is accessible */
***
*** 1700,1707
preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE;
preload_bootstrap_relocate(KERNBASE);
}
- if (bootinfo.bi_envp)
- kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
}
#if defined(I586_CPU) !defined(NO_F00F_HACK)
--- 1719,1724
Thanks,
Drew
--
Andrew Gallatin, Sr Systems Programmerhttp://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer SciencePhone: (919) 660-6590
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: npx0 to set maxmem broken in -current?
a bit late you should check teh cvs rep for these files.. peter's already checked it in... :-) Don't count on Peter's changes; I'm going to try to beat them up again. -- \\ 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-hackers" in the body of the message
Re: npx0 to set maxmem broken in -current?
Julian Elischer writes: a bit late you should check teh cvs rep for these files.. peter's already checked it in... :-) Wow, he's fast. ;-) I should have checked my committers folder sooner.. Thanks Peter. Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Usage of 'gdb' command in DDB
Hello All, Well, I entered 'gdb', then 'continue' and now I can debug the kernel remotely. How do I switch DDB back? Ctrl-Alt-Esc now causes DDB to contact the remote GDB instead of accepting input from me. Thank you, Stan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: reason for slow user-user memory copy
If the mapping is being done via a device mapping, then the region will be marked non-cacheable. I remember that he said he created a character device /dev/tulip to represent the network card. Actually, his work borrowed a lot from the Cornell U-Net project (now the basis of VIA?). Can we change the corresponding page table (directory) entries to be cacheable as needed? You'd have to modify the kernel - specifically pmap_mapdev(). Note that the above behavior is only true for older versions of FreeBSD (pre-2.2). If you're having this problem within a newer version of FreeBSD, then it's probably something else causing it. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard problems
On Thursday, 1 July 1999 at 13:08:11 -0700, Mike Smith wrote: Indeed. Is it possibly interrupting on a line which something else is using? I've found a problem on my Latitude where it appears that the machine only has two interrupts free (3 and 9). If I put a modem on 3 and an Ethernet board on 9, it works, but only by putting pccardd on irq 5, which doesn't really work. If I pull the Ethernet card, the whole machine hangs up when I try to access the net, presumably because pccardd hasn't found out about it. Have you tried setting the PCIC IRQ to 0, so that the driver polls instead? I have now. It ignored it and grabbed irq 5 anyway. Where is this described? I put it in my config file: # PCCARD (PCMCIA) support controller card0 device pcic0 at card? irq 0 device pcic1 at card? irq 0 Is that what you meant? 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-hackers" in the body of the message
Re: Lizard...
Feel free, just don't ask me questions about it since I honestly don't have time right now to explain to many hundreds of people how to build this stuff. In a nutshell, use egcs to compile everything from the following list: turbovision 0.7, qt 1.42, libh 0.1 (see below). libh is the code in question and can be obtained from ftp://zippy.cdrom.com/pub/libh.tar.gz. It will work with either gmake or make. FWIW it seems to want GNU make. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard problems
In message [EMAIL PROTECTED] Greg Lehey writes: : Is that what you meant? No. You need to set machdep.pccard.pcic_irq to be zero in your boot loader. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pccard problems
On Wednesday, 30 June 1999 at 22:56:43 -0700, Dan Strick wrote: I am attempting to configure a couple of pccards on a DELL Inspiron 3500 running FreeBSD 3.2-RELEASE. Neither card works: 1) The first card is some sort of DVD/MPEG-2 decoder card. It seems to be called a DELL Margi. Whenever the card is inserted and pccardd is running, the entire system hangs so hard that console I/O no longer works. Even ctl-alt-del is ignored. The power button is ignored. I have to turn the machine off by poking a special hidden recessed button on the side with a paper clip. I don't expect to find a FreeBSD driver for this card, but I would prefer that having it physically installed didn't hang the system. Indeed. Is it possibly interrupting on a line which something else is using? I've found a problem on my Latitude where it appears that the machine only has two interrupts free (3 and 9). If I put a modem on 3 and an Ethernet board on 9, it works, but only by putting pccardd on irq 5, which doesn't really work. If I pull the Ethernet card, the whole machine hangs up when I try to access the net, presumably because pccardd hasn't found out about it. 2) The second card is a DELL 10/100 LAN+56K Modem CardBus by 3Com. A label on the back of the card says Model 3CCFEM656. The command pccardc dumpcis reports: Configuration data for card in slot 1 Tuple #1, code = 0xff (Terminator), length = 0 I assume that pccardd cannot recognize and configure cards without configuration data. Is this card broken in some sense? Can anyone recommend a driver? I've seen this kind of problem on my Latitude laptop after running Microsoft. It seems that Microsoft sets the board state in such a way that a simple reboot doesn't reset it, and this is the result. If I power down the machine and then boot it with FreeBSD, I don't have any problems. Have you tried that? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: DVD-ram
* Kenneth D. Merry (k...@plutotech.com) [990701 07:56]: No, its SCSI, im using a adaptec adapter. Keep in mind that i am unfamiliar with SCSI devices so I might allready be doing/have done something stupid ; ) It's not SCSI. The acd driver is the ATAPI CD driver. If you had a SCSI DVD drive, it would show up as 'cd0'. Sorry, the actual dmesg for the device is cd0 at ahc0 bus 0 target 6 lun 0 cd0: MATSHITA PD-2 LF-D100 A110 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [1218960 x 2048 byte records] I apologise for the confusion. -crypt0genic -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website:http://www.ecad.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Annoucing: FreeBSD-3.2-Express, a multi-filesystem capable FreeBSD
Dear all, It is to announce the availability of FreeBSD-3.2-Express on ftp://ftp.freebsd.org/pub/FreeBSD/development/3.2-express. FreeBSD-3.2-Express is now capable of being hosted on local/remote disk drives of FAT/NTFS/UFS/EXT2FS/NFS and ISO-9660 to take the benefits of harddisk and/or network performance. One don't even need any CD-writer nor CD-ROM to play with FreeBSD. Compared to FreeBSD-3.1-Express, most user configurable files are now placed on the MFS, memory file system, and are user customisable. Tools for backup , 'snap' and 'resume' are shell scripts to ease re-configurations. Also, 'express.sh' under /misc may be used to install the contents of 3.2-Express onto installed 3.2-RELEASE. Numerous packages had been added, such as CORBA 2 compliant ILU, OODBMS PostgreSQL-6.5, File manager XFM, gimp-1.1.5, lyx-1.0.2, abs-0.6a, apache-1.3.6, webmin-0.72, xwpe, ddd-3.1.5, jdk1.1.8-elf, lesstif-0.88.1, samba-2.0.4b, mars_nwse, netatalk-asun, fwtk-2.1, Xvnc-3.3.2, mapedit, acroread, mpsql-2.1, python-1.5.2, ssh. Also, the kernel had been upgraded to include ipfw capability featuring DUMMYNET bandwidth management and BRIDGE. bpf, ccd-capable, vinum, svr4, nwfs as loadable modules. lesstif's mwm, mlvwm(mac lookalike) and qvwm(windows lookalike) are window-manager switchable on the fly, Xwindow configurations being a one-click distance under xfm, editor of vi, ee, vim, nedit of choices. shells of sh, csh, ksh, bash, tcsh for to be choose among. cxterm been configured for both big5 and gb encoding and xcin installed. Xservers are now true-type-font capable. If you're to view the contents of packages on FreeBSD-3.2-Express, please read the MANIFEST.TXT on the CD. Enclosed is the README.TXT found on the url above. Enjoy, -- Best wishes, / ___/ /___/Clarence Chu / // c...@hkstar.com / / / http://www.hkstar.com/~clc Encl. FreeBSD-3.2-EXPRESS (C) Copyright 1999 Data Expert Limited. All rights reserved. Running the CD -- If you do not have access to a bootable CD-ROM drive for running, you will have to generate two 1.44MB bootable floppies under \INSTALL\kern.flp and \INSTALL\mfsroot.flp by using \INSTALL\fdimage.exe under DOS, consult \INSTALL\README.TXT. vn(4), vinum(8), ccd(4), mount_ntfs(8), mount_ext2fs(8), mount_nwfs(8), mount_cd9660(8), smbclient(8), mount_msdos(8) as well as mount_nfs(8) are working on the CD. To use X-window System with only the CD, optinally configure the network details and choose eXpress. A default XF86Config file had been placed under /etc, for resolution of 1024x768-8bpp of SVGA compatible card. you may run x11 [gui], startx, xinit, xlogin [hostname] or Xwrapper options to start the X-window System. If the XF86Config does not match your hardware, reconfigure it by xf86config or XF86Setup. Xdm had been started for network connections, users may login from their X-server and may execute the X-clients. Lpd, httpd, sendmail and webmin for administration had been started, too. Xvnc had been installed, try http://hostname:5800+DISPLAY_NO/ after running 'vncserver' script. About 200 packages of all types had been installed onto the CD as executable binaries, please consult /MANIFEST.TXT on the CD by www browsers. Quick installation of XF86Config for 1152x900, 1024x768, 800x600 and 640x480 with depth 8/16/24/32 is provided. Issue 1152 3 for 1152x900 with 24bpp, 1024i 2 for 1024x768 with 16bpp for interlaced display, etc. Release Notes - a) Visit http://www.freebsd.org for general information. b) SVR4 emulation do work on the CD, /cdrom/misc/svr4.txt c) Linux emulation works, consult /cdrom/misc/staroffice.txt d) Netware clients had been added, see /cdrom/misc/ipx.html e) Ntfs (smbclient on CD) added, mount_ntfs(8) and smbclient(8) f) For professional support, visit http://www.dexpert.com. FreeBSD-3.2-Express How to run it most efficiently === FreeBSD-3.2-Express is capable of running even without a local CD-ROM drive. Just prepare the ISO-9660 image (by your favorite cdrecording software or dd(1) of any *nix), and place it onto your FAT/NTFS/UFS/EXT2FS/NFS drive space. Then use the /INSTALL/*.flp floppies or the 3.2-Express CD to boot up the box. By using the HoloShell of the 3.2-express main menu, mount
Webcams?
I'm planning of setting up a webcam under freebsd (4.0-CURRENT) What webcams work good with FreeBSD? thnx in advance /*Erik Meyer eri...@display-umea.se*/ /*work(+46(0)90177963) */ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: DVD-ram
crypt0genic crypt0ge...@ecad.org writes: I have a Lacie DVD-RAM drive, it work great under windows, here is the DMESG i g et from it, I hope this is of some help. LaCie don't make drives, they just package them in ugly boxes with noisy fans. One of my cow-orkers (with whom I share an office) had an external LaCie disk hooked up to his Mac until I threatened to pour Coca Cola into the PSU (this was after I'd hinted several times that the handles on his G3 would serve very well for chucking it out the window) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: DVD-ram
* Dag-Erling Smorgrav (d...@flood.ping.uio.no) [990701 11:47]: LaCie don't make drives, they just package them in ugly boxes with noisy fans. Im not sure what model you are refering too, but the drive I have is in a stylish external box with a fan that doesnt make a whisper on noise, It also doesnt make any sound when reading/writeing. The unit is so sturdy I rekon I could through it at a brick wall without damaging it! Overall Im very pleased with this piece of hardware and when it is supported under freebsd it will be one of my most prised devices. : ) -crypt0genic -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website:http://www.ecad.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: DVD-ram
crypt0genic crypt0ge...@ecad.org writes: * Dag-Erling Smorgrav (d...@flood.ping.uio.no) [990701 11:47]: LaCie don't make drives, they just package them in ugly boxes with noisy fans. Im not sure what model you are refering too, but the drive I have is in a stylish external box with a fan that doesnt make a whisper on noise, It also doesnt make any sound when reading/writeing. The unit is so sturdy I rekon I could through it at a brick wall without damaging it! Overall Im very pleased with this piece of hardware and when it is supported under freebsd it will be one of my most prised devices. : ) The box may look solid, but the drive inside is a standard OEM component (Matshita, IIRC) which would certainly not survive the impact, no matter how sturdy an enclosure it's in - unless the enclosure has internal shock mounts, which would frankly surprise the hell out of me given LaCie's generally low prices. You get what you pay for. And the fan may be nice and silent now, but how do you know that'll last? My cow-orker's unit was two months old when the fan started screaming like a butchered pig. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Postfix license update.
Just to let you all know, it appears that the termination clause has been dropped, but it appears to have gained a gpl-like must make source available clause. http://msgs.securepoint.com/cgi-bin/get/postfix9906/103.html (and where I found it) http://www.lwn.net/1999/0701/a/postfix.html -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Postfix license update.
On Thu, Jul 01, 1999 at 01:27:38PM +0100, Dominic Mitchell wrote: Just to let you all know, it appears that the termination clause has been dropped, but it appears to have gained a gpl-like must make source available clause. http://msgs.securepoint.com/cgi-bin/get/postfix9906/103.html (and where I found it) http://www.lwn.net/1999/0701/a/postfix.html This has been discussed at the postfix-us...@postfix.org mailing list, just download the newest version, and you will see it .. /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.bin/ftp Makefile fetch.c ftp.1 ftp.c ftp_var.h main.c util.c
On Thu, Jul 01, 1999 at 03:03:12PM +0200, Dag-Erling Smorgrav wrote: Ruslan Ermilov r...@freebsd.org writes: On Thu, Jul 01, 1999 at 01:51:24PM +0200, Eivind Eklund wrote: On Thu, Jul 01, 1999 at 04:33:37AM -0700, Ruslan Ermilov wrote: - separate the pftp and FTP_PASSIVE_MODE tests so gate mode works again PR: bin/12070 - specifically check that FTP_PASSIVE_MODE is set to YES, rather than just checking if it is defined We elected to change our defaults to having passive mode enabled - it sounds to me like it should explicitly check for FTP_PASSIVE_MODE=NO, not vice versa. [for some reason, Eivind's mail hasn't reached me yet] This is because my mail was a private mail to Ruslan, because I didn't feel that the issue was worth filling the committers list with (or really, interesting for anybody but me and the author of the code, which I thought was Ruslan). As it seems Ruslan feels differently, I'm keeping a public Cc:, but moving to -hackers. Eivind: what Ruslan just did was MFC some patches I committed a week or two ago but hadn't come around to MFCing yet (these were the patches I mentioned yesterday). If you had any objections, you should have raised them back then... Sorry; didn't notice back then. * 'unset FTP_PASSIVE_MODE' (or hack login.conf), which always worked * set FTP_PASSIVE_MODE=NO, which didn't work before the patch, because ftp(1) would just notice that FTP_PASSIVE_MODE was defined and assume it meant it should use passive mode. Some may find the second solution more obvious than the first; hence the PR and my patches. Changing ftp(1) to check for FTP_PASSIVE_MODE=NO rather than the reverse would gratuitously change ftp's reaction to its environment. Not at the first point this was done; it would avoid gratiously changing the reaction. Ie: Index: main.c === RCS file: /home/ncvs/src/usr.bin/ftp/main.c,v retrieving revision 1.18 diff -u -r1.18 main.c --- main.c 1999/06/25 14:11:15 1.18 +++ main.c 1999/07/01 14:41:35 @@ -135,7 +135,7 @@ cp = strrchr(argv[0], '/'); cp = (cp == NULL) ? argv[0] : cp + 1; if ((s = getenv(FTP_PASSIVE_MODE)) != NULL -strcasecmp(s, yes) == 0) +strcasecmp(s, no) != 0) passivemode = 1; if (strcmp(cp, pftp) == 0) passivemode = 1; ... compared to the sources as of today. This gives minimal semantic difference from the way it worked before the change (which was that if FTP_PASSIVE_MODE existed, ftp used passive mode). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Lizard...
Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: GRE encapsulation under FreeBSD 3.2
In article local.mail.freebsd-hackers/19990630153542.a31...@lunatic.oneinsane.net you write: On Wed, 30 Jun 1999, Jonathan Lemon was heard blurting out: In article local.mail.freebsd-hackers/pine.bsf.4.05.9906301438450.10384-100...@medulla.hippocampus.net you write: I don't seem to see support for GRE (IP-in-IP encaspulation) in FreeBSD (although I might be blind)...anyone working on support it or is there already an implementation? Yes, I've grabbed the GRE support from NetBSD, and have it working here (as far as I can tell). I'll commit it in a day or two. -- Jonathan Does this mean NATD/VPN using the -pptpalias will work for the clients that are using M$ VPN? If so, the sooner the better for me. Hmm, I don't know what that is, nor what relation it has to GRE. Do you hve an URL that would enlighten me? -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
npx0 to set maxmem broken in -current?
I have a user with a need to run a machine in varying memory configurations. The machine has 512MB she needs to artificially constrain memory to multiples of 32MB from 32MB to 512MB. (32MB, 64MB, 96MB, 128MB ...) I was planning on having her edit /kernel.config change the value of iosize npx0 and have the bootloader do a load -t userconfig_script /kernel.config at boottime. However, this feature appears to be broken in current. The resource_int_value() call which grabs msize is returning ENOENT we're seeing the full 512MB of ram. Is there any way around this, short of building her 16 different kernels? Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: galla...@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
Andrew Gallatin wrote: I have a user with a need to run a machine in varying memory configurations. The machine has 512MB she needs to artificially constrain memory to multiples of 32MB from 32MB to 512MB. (32MB, 64MB, 96MB, 128MB ...) I was planning on having her edit /kernel.config change the value of iosize npx0 and have the bootloader do a load -t userconfig_script /kernel.config at boottime. However, this feature appears to be broken in current. The resource_int_value() call which grabs msize is returning ENOENT we're seeing the full 512MB of ram. Is there any way around this, short of building her 16 different kernels? The npx0 tuneing hack has been broken for ages and never worked well anyway. Originally, it depended on dset working, because by the time userconfig ran, memory had already been sized and set up and it was way too late. However, dset would modify the kernel binary so that next time it ran the changes would be available early enough. Now it's even worse since the resource_* routines use the config(8) generated tables (see config.c) until malloc is up and running and then it switches over to using malloc for backing. Personally, I think we should use a kernel environment variable passed in from loader, since kern_envp is available *real early*, from the very beginning of init386(), which is called form locore just after going virtual. It needs a couple of tweaks to get this to work, and in particular, the environment variable will have to override the VM86 calls. Cheers, -Peter -- Peter Wemm - pe...@freebsd.org; pe...@yahoo-inc.com; pe...@netplex.com.au To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
Reminds me of SCO. I personally don't much like it- it makes it harder than hell to figure out what's gone wrong when it doesn't work. On Thu, 1 Jul 1999, Steve Ames wrote: Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
True... But such a configuration doesn't preclude the use of a more detailed listing on vty1 the way we do it now. With our current installation setup its similar to this already. Its text based and some of the menus are not exactly intuitive (No... I don't have a better suggestion just yet). If something goes wrong you don't really know what unless you look at the second vty (ALT-F2) and then (maybe) there is some good info there. I've had a lot of installs go awry with little information to explain to me what went wrong. Like you, I'd prefer a very primitive interface if it gave me lots more diagnostics. Joe Average, on the other hand, likes a spiffy, clean interface. We try to accomodate both types by having a simplistic install and then some detail output on a seperate VTY. This could still be done with an even spiffier graphical installation on the first VTY. Wonder if it utilizes the VGALIB? (Lizard that is) Reminds me of SCO. I personally don't much like it- it makes it harder than hell to figure out what's gone wrong when it doesn't work. On Thu, 1 Jul 1999, Steve Ames wrote: Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
if it gave me lots more diagnostics. Joe Average, on the other hand, likes a spiffy, clean interface. We try to accomodate both types by having a simplistic install and then some detail output on a seperate VTY. This could still be done with an even spiffier graphical installation on the first VTY. Possibly. It's not clear what or who Joe Average is here. I suspect that 99% of all computer users (by volume) get their s/w preinstalled. The amount of sophistication of the remaining 1% who actually struggle through so-called spiffy installs is growing exponentially. Keeping a simple interface rather than trying to play human engineering with no real human interfaces lab and a 500K$ testing budget might be better. Just my 2 cents... I'll shut up now... (I mean, why should *I* beef so much? I'm not writing or maintaining sysinst...) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
In article local.mail.freebsd-hackers/19990701181449.846a...@overcee.netplex.com.au you write: Personally, I think we should use a kernel environment variable passed in from loader, since kern_envp is available *real early*, from the very beginning of init386(), which is called form locore just after going virtual. It needs a couple of tweaks to get this to work, and in particular, the environment variable will have to override the VM86 calls. You'd still have to perform the VM86 calls, since one of the things they do is generate a map of where the useable memory segments are. The environment variable would be used later (at the same point where the npx0 hack is) in order to cap Maxmem. I like the idea of being able to say: set console=comconsole set maxmem= boot -- Jonathan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
through so-called spiffy installs is growing exponentially. Keeping a simple interface rather than trying to play human engineering with no real human interfaces lab and a 500K$ testing budget might be better. Just my 2 cents... I'll shut up now... (I mean, why should *I* beef so much? I'm not writing or maintaining sysinst...) OK, I'll add a few comments to this. I've looked at the screen shots to lizard and have to say that for a certain type of user, it looks pretty approachable. That type of user is specifically the Windows user, someone who'll have certain assumptions about how dialogs look, what kinds of questions they're asked and so on. It's clear from looking at the screenshots that Lizard tries to be extremely Windows-like and that's probably going to make a reasonable number of people happy; if it's what they're used to, there's really no arguing the point. However, we're also not going for the desktop market quite as aggressively head-on as Caldera is and we have an ISP installed base which would also get very persnickety if our installer started shedding usability in the generic cases in favor of a flashy, focused-on-the-desktop installation. What I mean specifically by that is that we still need to be able to install over a serial line with no keyboard or VGA card plugged into the machine, we still need to support scripted installs (even better than we currently support them) and we need to add support for a number of other features like master/slave installations (one master, n clones), adequate OS and component upgrades, high-level repair/recovery, etc. All the sorts of things that network server users seem to expect and a really whiz-bang graphical install can get in the way of if you aren't extremely careful not to code toward that single goal and have a very flexible approach to the UI. Of course, things can also go too much the other way and sysinstall is a good example of an installer which is significantly constrained just by its UI. The hateful libdialog library has a maximum number of 2 buttons on its standard proceed/cancel dialogs, for example, and there's no easy way to add a Back to many of the installation dialogs which could really benefit from one. There are also no tab boxes or panners or any other UI elements for putting more than one screen-full's worth of data up in a useful fashion, that is to say which is easily selectable by the user and with an event model that supports arbitrary call-outs. For the last 3 years or so at least, I've also been stuck in the unenviable position of knowing everything that needs to be done to fix the installer and underlying package tools (e.g. rewrite them from scratch) but having a progressively decreasing amount of time to even think about doing it. About a year ago, I even got a paid contractor working on doing some code and he managed to generate some very promising looking stuff, then my time even for interacting with him became so spotty that he finally got annoyed with me and downed tools on the project until he could get some real and effective feedback from us. My bad, as the current generation says, and it's a major item on my TODO list to spend about 2 days pouring through his code and generating a comprehensive set of comments about where to go from there. Unfortunately, this code is also in the very early stages and represents about 34,000 lines of uncommented C++ and TCL code which requires egcs, turbovision 0.7 and (optionally) Qt 1.42 to build so the learning/testing curve is a bit steep. Every person I've handed a copy to so far has never reported back with anything to pass on to the contractor in question.. :) So anyway, that's why (in a nutshell) that sysinstall and pkg_install continue to get patched and ammended even though we all know how limited and hacked-together they are as tools. :) - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
OK, I'll add a few comments to this. And I'll respond... The actual pros and cons of the current installer and what a new one would look like is not the real question to answer here,... I have to say that what we have isn't that bad- it fails only in some areas where it violates the principle of least surprise. It's quite similar to the Slackware install in that it's simple but does have some fastpath items that work for a large number of cases and it tries to sanity check as it goes. That's really all that's needed for almost all the cases (I assert). I'm really not sure that the Windows-like look is a smart move. I mean, KDE looks like a VGA version of win95 and this was all a clever joke with fvwm95 but it's wearing thin. What actual marketing information do we actually have that says that in order to go after the desktops we aren't currently installed on we have to add a lot of engineering effort to the installer? Would it be better to try and work some deals with Compaq or Dell (so that they hedge their bets on Linux) and be a preinstalled choice for those systems instead of trying go after the (exceedingly rare and getting rarer) desktop user who actually installs an entire OS from CD? -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
What actual marketing information do we actually have that says that in order to go after the desktops we aren't currently installed on we have to add a lot of engineering effort to the installer? Would it be better to Well, just to clear up what looks like a misunderstanding in the making, let me say that the engineering effort we're contemplating here has nothing to do with going after the desktop, it has to do with better security, better componentization(?) of the OS and 3rd party apps, better upgrades, better underlying technology basically. :) - JOrdan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
What actual marketing information do we actually have that says that in order to go after the desktops we aren't currently installed on we have to add a lot of engineering effort to the installer? Would it be better to Well, just to clear up what looks like a misunderstanding in the making, let me say that the engineering effort we're contemplating here has nothing to do with going after the desktop, it has to do with better security, better componentization(?) of the OS and 3rd party apps, better upgrades, better underlying technology basically. :) Whuf! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
My bad, as the current generation says, and it's a major item on my TODO list to spend about 2 days pouring through his code and generating a comprehensive set of comments about where to go from there. Unfortunately, this code is also in the very early stages and represents about 34,000 lines of uncommented C++ and TCL code which requires egcs, turbovision 0.7 and (optionally) Qt 1.42 to build so the learning/testing curve is a bit steep. Every person I've handed a copy to so far has never reported back with anything to pass on to the contractor in question.. :) Would it be possible to have this code put up for www/ftp or something, so that anyone who is interested could have a look? I, for one, would like to have a look at it. Nathan, not ready to commit to working on something like this. :( -- Nathan AhlstromFreeBSD: http://www.FreeBSD.org/ nrahl...@winternet.com PGP Key ID: 0x67BC9D19 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Thank you Peter!! (Was: Heavily loaded amd/nfs... )
I am very happy to report that with the recent commits to -current I can now run my script that reads some 16000 small files in over NFS links at full speed and to completion without locking the box. *BSEG* Many, many thanks for this, it was a huge area of concern for my boss that even though the box performed well under real world load it was falling down on this step (building configuration files). Chalk one up for the good guys. 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: pccard problems
Indeed. Is it possibly interrupting on a line which something else is using? I've found a problem on my Latitude where it appears that the machine only has two interrupts free (3 and 9). If I put a modem on 3 and an Ethernet board on 9, it works, but only by putting pccardd on irq 5, which doesn't really work. If I pull the Ethernet card, the whole machine hangs up when I try to access the net, presumably because pccardd hasn't found out about it. Have you tried setting the PCIC IRQ to 0, so that the driver polls instead? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Xfree86 v 3.3.4
Does anyone have any inside information on subj? The website still claims: We are planning to release 3.3.4 some time in June 1999 I'm longing to get support for my S3 Trio3D. Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... Show us how to a) script it, and b) make it run on a serial terminal, and you'll get a lot more of peoples' attention. 8) -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
Everyone should take a peak at http://www.troll.no/announce/lizard.html if you haven't already. Definately take a look at the screenshots. Lizard is a fully graphical Linux installation for Caldera Systems Open Linux. IMO, having an easy, reliable and attractive installer is an excellent selling point. Just something to ponder... Show us how to a) script it, and b) make it run on a serial terminal, and you'll get a lot more of peoples' attention. 8) *grin* Always the trick isn't it? I think Jordan pointed out all of the good stuff on this topic. Its pretty obvious that one install isn't going to meet everyone's need. FreeBSD does not focus on the desktop and so doesn't need a desktop oriented install. It has also been pointed out that most people don't install their own OS anway unless they have some semblence of technical knowledge or daring. These people don't need a hold-your-hand type install. That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) -Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
On Thu, 01 Jul 1999, Matthew Jacob was heard blurting out: That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. Just tried Redhat last month for the first time. Damn install is more confusing that FreeBSD.. Or maybe I just got accustomed to the freebsd install ;-) -- --- Ron Rosson ... and a UNIX user said ... The InSaNe One rm -rf * ins...@oneinsane.netand all was null and void --- Double your drive space: Delete Windows! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
Personally, I think we should use a kernel environment variable passed in from loader, since kern_envp is available *real early*, from the very beginning of init386(), which is called form locore just after going virtual. It needs a couple of tweaks to get this to work, and in particular, the environment variable will have to override the VM86 calls. It shouldn't override it, rather it should simply lower the current 4GB cap to whatever it's set to. This allows the BIOS sensing code to correctly walk around holes, etc. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. I'd have to concur. I've done both - actually - the RedHat really isn't that different from FreeBSD (that was RedHat 5.2.) - a few of nice boxes you fill in - pop the CD in the drive... *poof* - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Xfree86 v 3.3.4
On Thu, 1 Jul 1999, Leif Neland wrote: Does anyone have any inside information on subj? The website still claims: We are planning to release 3.3.4 some time in June 1999 I'm longing to get support for my S3 Trio3D. Heh. It now says early july. I have a Voodoo Banshee I want to use. David To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
UMAX scsi scanner on adaptec 1542 Card
I've been messing around for awhile, and I'm confused (go figure). I've got an adaptec 1542 card using aha driver and RELENG_3 detects it no problems. If I use the adaptec on board utilities it finds my UMAX scanner no probs. when I try to boot the machine hangs just after the waiting for scsi to settle message. So I've turned on cam debugging and get lots of iterations of (probe0:aha0:0:0:0) ahaaction (probe1:aha0:0:1:0) ahaaction (probe2:aha0:0:2:0) ahaaction (probe3:aha0:0:3:0) ahaaction (probe4:aha0:0:4:0) ahaaction (probe5:aha0:0:5:0) ahaaction (probe6:aha0:0:6:0) ahaaction and for a given probe (probe0:aha0:0:0:0) camisr(probe0:aha0:0:0:0 ) ahaaction (probe0:aha0:0:0:0) xpt_action (probe0:aha0:0:0:0) INQUIRY. CDB 12 0 0 0 24 0 (probe0:aha0:0:0:0) xtp_setupccb (probe0:aha0:0:0:0) xtp_action (probe0:aha0:0:0:0) CCB 0xc5692508 - timeout (probe0:aha0:0:0:0) CCB 0xc5692508 - timeout (probe0:aha0:0:0:0) ahaaction (probe0:aha0:0:0:0) camisr(probe0:aha0:0:0:0 ) probedone (probe0:aha0:0:0:0) xpt_compile_path (probe0:aha0:0:0:0) xpt_release_path (probe0:aha0:0:0:0) xpt_done aha0: No Longer in timeout I've gabbed these as best as I can since the machine doesn't finish booting so I can't grab a dmesg and I don't have a serial console. the kernel contains controller aha0at isa? port ? cam irq ? controller scbus0 #base SCSI code device da0 #SCSI direct access devices (aka disks) device sa0 #SCSI tapes device pass0 #CAM passthrough driver Any thoughts comments . clues for the clueless . TIA Greg -- Email: ska...@worldgate.com Voice: +780 413 1910Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
Mike Smith wrote: Personally, I think we should use a kernel environment variable passed in from loader, since kern_envp is available *real early*, from the very beginning of init386(), which is called form locore just after going virtual. It needs a couple of tweaks to get this to work, and in particular, the environment variable will have to override the VM86 calls. It shouldn't override it, rather it should simply lower the current 4GB cap to whatever it's set to. This allows the BIOS sensing code to correctly walk around holes, etc. Also, bear in mind the fun we had with BIOS reporting 15MB of ram and the like.. Capping is fine, so long as there's some way of forcing it to a given value if needed. Never assume BIOS writers are *always* competent. :-) Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Xfree86 v 3.3.4
There is a Linux X server for the Voodoo Banshee, over at: http://developer.soundblaster.com/linux/ You might have some luck running it under the Linux emulator. I've never tried it, as I don't have a Banshee. -Mark Taylor NetMAX Developer mtay...@cybernet.com http://www.netmax.com/ On 01-Jul-99 David Scheidt wrote: On Thu, 1 Jul 1999, Leif Neland wrote: Does anyone have any inside information on subj? The website still claims: We are planning to release 3.3.4 some time in June 1999 I'm longing to get support for my S3 Trio3D. Heh. It now says early july. I have a Voodoo Banshee I want to use. David To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
reason for slow user-user memory copy
A graduate student here implements a mmap() interface to a TCP/IP network card. He notices that it takes much longer time to copy from mmapp()'ed area to another user area than it takes to copy the same amount of data from kernel space to user space. The students here have no idea why this could be possible. I hope someone on this list can give us a hint. Below is a part of his original email. He uses rdtsc instruction to do the timing. Well I have implemented a memory mapped interface for the user in Linux using the DEC 21140 Tulip ethernet card. Thus the user has access to the buffers, but when I did a memcpy from the RX buffer to the user variable, it took an extraordinary amount of time, approx 70 microsec for 1460 btyes... where as the original scheme takes 25 microsec for the same data when it does a memcpy_to_iovec in tcp_recvmsg(). I am confused by this unexpected timings. More than 80% of the time is spent doing the memcpy. --- Thanks for your help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: reason for slow user-user memory copy
hmm Unfortunatly Linux is nt relevent to FreeBSD so we can't comment directly.. it is possible that the mmapped region is marked non-cachable, which migh tmake a difference. I have no idea where memcpy_to_iovec in Linux is copying to so it's hard to comment. julian On Thu, 1 Jul 1999, Zhihui Zhang wrote: A graduate student here implements a mmap() interface to a TCP/IP network card. He notices that it takes much longer time to copy from mmapp()'ed area to another user area than it takes to copy the same amount of data from kernel space to user space. The students here have no idea why this could be possible. I hope someone on this list can give us a hint. Below is a part of his original email. He uses rdtsc instruction to do the timing. Well I have implemented a memory mapped interface for the user in Linux using the DEC 21140 Tulip ethernet card. Thus the user has access to the buffers, but when I did a memcpy from the RX buffer to the user variable, it took an extraordinary amount of time, approx 70 microsec for 1460 btyes... where as the original scheme takes 25 microsec for the same data when it does a memcpy_to_iovec in tcp_recvmsg(). I am confused by this unexpected timings. More than 80% of the time is spent doing the memcpy. --- Thanks for your help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: reason for slow user-user memory copy
A graduate student here implements a mmap() interface to a TCP/IP network card. He notices that it takes much longer time to copy from mmapp()'ed area to another user area than it takes to copy the same amount of data from kernel space to user space. The students here have no idea why this could be possible. I hope someone on this list can give us a hint. Below is a part of his original email. He uses rdtsc instruction to do the timing. Well I have implemented a memory mapped interface for the user in Linux using the DEC 21140 Tulip ethernet card. Thus the user has access to the buffers, but when I did a memcpy from the RX buffer to the user variable, it took an extraordinary amount of time, approx 70 microsec for 1460 btyes... where as the original scheme takes 25 microsec for the same data when it does a memcpy_to_iovec in tcp_recvmsg(). I am confused by this unexpected timings. More than 80% of the time is spent doing the memcpy. --- If the mapping is being done via a device mapping, then the region will be marked non-cacheable. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
Peter Wemm writes:
Peter,
Thanks for the details. I wasn't sure if it was something that was
supposed to work... I assume it still works when built in by config
should be left in place for that reason though, right? (haven't tried
it here..)
Personally, I think we should use a kernel environment variable passed in
from loader, since kern_envp is available *real early*, from the very
beginning of init386(), which is called form locore just after going
virtual. It needs a couple of tweaks to get this to work, and in
particular, the environment variable will have to override the VM86
calls.
Great idea! I'd thought about adding a boot flag, but didn't realize
the kernel environment variable route was so easy.
The following hack seems to work here. At least it should have the
same effect as building with MAXMEM. The only bit that concerns me is
the movement of the movement of the kern_envp initialzation. I don't
know diddly about the early stages of the boot I don't know if
moving it so that environment variables are available in getmemsize()
is safe. Can you take a peek at this patch please?
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.342
diff -u -b -B -c -r1.342 machdep.c
cvs diff: conflicting specifications of output style
*** machdep.c 1999/06/18 14:32:14 1.342
--- machdep.c 1999/07/01 23:28:50
***
*** 153,158
--- 153,164
CTLFLAG_RD, tlb_flush_count, 0, );
#endif
+ int i386_maxmem=0;
+
+ SYSCTL_INT(_machdep, OID_AUTO, maxmem, CTLFLAG_RD,
+ i386_maxmem, 0, override memory auto-size at boottime);
+
+
#ifdef PC98
static intispc98 = 1;
#else
***
*** 1331,1337
/*
* If a specific amount of memory is indicated via the MAXMEM
!* option or the npx0 msize, then don't do the speculative
* memory probe.
*/
#ifdef MAXMEM
--- 1337,1344
/*
* If a specific amount of memory is indicated via the MAXMEM
! * option or the npx0 msize, or the machdep.maxmem kernel
! * environment variable, then don't do the speculative
* memory probe.
*/
#ifdef MAXMEM
***
*** 1347,1352
--- 1354,1365
}
}
#endif
+ if (getenv_int(machdep.maxmem, i386_maxmem) != 0) {
+ if(i386_maxmem != 0) {
+ Maxmem = i386_maxmem / 4;
+ speculative_mprobe = FALSE;
+ }
+ }
#ifdef SMP
/* look for the MP hardware - needed for apic addresses */
***
*** 1656,1661
--- 1669,1680
dblfault_tss.tss_ldt = GSEL(GLDT_SEL, SEL_KPL);
vm86_initialize();
+ /*
+* moved here to make machdep.maxmem available in
+* getmemsize. Not sure if this is safe
+*/
+ if (bootinfo.bi_envp)
+ kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
getmemsize(first);
/* now running on new page tables, configured,and u/iom is accessible */
***
*** 1700,1707
preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE;
preload_bootstrap_relocate(KERNBASE);
}
- if (bootinfo.bi_envp)
- kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
}
#if defined(I586_CPU) !defined(NO_F00F_HACK)
--- 1719,1724
Thanks,
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: galla...@cs.duke.edu
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: reason for slow user-user memory copy
On Thu, 1 Jul 1999, David Greenman wrote: A graduate student here implements a mmap() interface to a TCP/IP network card. He notices that it takes much longer time to copy from mmapp()'ed area to another user area than it takes to copy the same amount of data from kernel space to user space. The students here have no idea why this could be possible. I hope someone on this list can give us a hint. Below is a part of his original email. He uses rdtsc instruction to do the timing. Well I have implemented a memory mapped interface for the user in Linux using the DEC 21140 Tulip ethernet card. Thus the user has access to the buffers, but when I did a memcpy from the RX buffer to the user variable, it took an extraordinary amount of time, approx 70 microsec for 1460 btyes... where as the original scheme takes 25 microsec for the same data when it does a memcpy_to_iovec in tcp_recvmsg(). I am confused by this unexpected timings. More than 80% of the time is spent doing the memcpy. --- If the mapping is being done via a device mapping, then the region will be marked non-cacheable. -DG I remember that he said he created a character device /dev/tulip to represent the network card. Actually, his work borrowed a lot from the Cornell U-Net project (now the basis of VIA?). Can we change the corresponding page table (directory) entries to be cacheable as needed? -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
a bit late
you should check teh cvs rep for these files..
peter's already checked it in... :-)
On Thu, 1 Jul 1999, Andrew Gallatin wrote:
Peter Wemm writes:
Peter,
Thanks for the details. I wasn't sure if it was something that was
supposed to work... I assume it still works when built in by config
should be left in place for that reason though, right? (haven't tried
it here..)
Personally, I think we should use a kernel environment variable passed in
from loader, since kern_envp is available *real early*, from the very
beginning of init386(), which is called form locore just after going
virtual. It needs a couple of tweaks to get this to work, and in
particular, the environment variable will have to override the VM86
calls.
Great idea! I'd thought about adding a boot flag, but didn't realize
the kernel environment variable route was so easy.
The following hack seems to work here. At least it should have the
same effect as building with MAXMEM. The only bit that concerns me is
the movement of the movement of the kern_envp initialzation. I don't
know diddly about the early stages of the boot I don't know if
moving it so that environment variables are available in getmemsize()
is safe. Can you take a peek at this patch please?
Index: machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
retrieving revision 1.342
diff -u -b -B -c -r1.342 machdep.c
cvs diff: conflicting specifications of output style
*** machdep.c 1999/06/18 14:32:14 1.342
--- machdep.c 1999/07/01 23:28:50
***
*** 153,158
--- 153,164
CTLFLAG_RD, tlb_flush_count, 0, );
#endif
+ int i386_maxmem=0;
+
+ SYSCTL_INT(_machdep, OID_AUTO, maxmem, CTLFLAG_RD,
+ i386_maxmem, 0, override memory auto-size at boottime);
+
+
#ifdef PC98
static int ispc98 = 1;
#else
***
*** 1331,1337
/*
* If a specific amount of memory is indicated via the MAXMEM
! * option or the npx0 msize, then don't do the speculative
* memory probe.
*/
#ifdef MAXMEM
--- 1337,1344
/*
* If a specific amount of memory is indicated via the MAXMEM
! * option or the npx0 msize, or the machdep.maxmem kernel
! * environment variable, then don't do the speculative
* memory probe.
*/
#ifdef MAXMEM
***
*** 1347,1352
--- 1354,1365
}
}
#endif
+ if (getenv_int(machdep.maxmem, i386_maxmem) != 0) {
+ if(i386_maxmem != 0) {
+ Maxmem = i386_maxmem / 4;
+ speculative_mprobe = FALSE;
+ }
+ }
#ifdef SMP
/* look for the MP hardware - needed for apic addresses */
***
*** 1656,1661
--- 1669,1680
dblfault_tss.tss_ldt = GSEL(GLDT_SEL, SEL_KPL);
vm86_initialize();
+ /*
+ * moved here to make machdep.maxmem available in
+ * getmemsize. Not sure if this is safe
+ */
+ if (bootinfo.bi_envp)
+ kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
getmemsize(first);
/* now running on new page tables, configured,and u/iom is accessible */
***
*** 1700,1707
preload_metadata = (caddr_t)bootinfo.bi_modulep + KERNBASE;
preload_bootstrap_relocate(KERNBASE);
}
- if (bootinfo.bi_envp)
- kern_envp = (caddr_t)bootinfo.bi_envp + KERNBASE;
}
#if defined(I586_CPU) !defined(NO_F00F_HACK)
--- 1719,1724
Thanks,
Drew
--
Andrew Gallatin, Sr Systems Programmerhttp://www.cs.duke.edu/~gallatin
Duke University Email: galla...@cs.duke.edu
Department of Computer SciencePhone: (919) 660-6590
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))
On Wed, Jun 30, 1999 at 08:02:06PM -0500, Stan Shkolnyy wrote: On Wed, 30 Jun 1999, Nik Clayton wrote: Sorry it's taken me a while to reply to this; ironically, most of my time has been spent on freebsd-doc recently. On Sat, Jun 26, 1999 at 12:03:59PM -0500, Constantine Shkolny wrote: I've come to understanding that lack of documentation is probably one of the factors that keep the system healthy, I've just spent five minutes trying to phrase a reply to this that manages to convey my complete disagreement without resorting to profanity. But why did you do that? Basically, I wanted to make sure my disagreement got on record somewhere, so that if anyone trawls the mailing lists at some point in the future and sees your comments, hopefully they'll also see my reply. I know your original comment was intended at least half in jest. But there'll be people who see it and take it the wrong way -- either by assuming that FreeBSD's attitude is too elitist, or that their efforts at documentation won't be welcome, and so on. N PS: Also, there's the considerable thrill of using naughty words. . . -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
a bit late you should check teh cvs rep for these files.. peter's already checked it in... :-) Don't count on Peter's changes; I'm going to try to beat them up again. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: npx0 to set maxmem broken in -current?
Julian Elischer writes: a bit late you should check teh cvs rep for these files.. peter's already checked it in... :-) Wow, he's fast. ;-) I should have checked my committers folder sooner.. Thanks Peter. Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: galla...@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Usage of 'gdb' command in DDB
Hello All, Well, I entered 'gdb', then 'continue' and now I can debug the kernel remotely. How do I switch DDB back? Ctrl-Alt-Esc now causes DDB to contact the remote GDB instead of accepting input from me. Thank you, Stan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: reason for slow user-user memory copy
If the mapping is being done via a device mapping, then the region will be marked non-cacheable. I remember that he said he created a character device /dev/tulip to represent the network card. Actually, his work borrowed a lot from the Cornell U-Net project (now the basis of VIA?). Can we change the corresponding page table (directory) entries to be cacheable as needed? You'd have to modify the kernel - specifically pmap_mapdev(). Note that the above behavior is only true for older versions of FreeBSD (pre-2.2). If you're having this problem within a newer version of FreeBSD, then it's probably something else causing it. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: pccard problems
On Thursday, 1 July 1999 at 13:08:11 -0700, Mike Smith wrote: Indeed. Is it possibly interrupting on a line which something else is using? I've found a problem on my Latitude where it appears that the machine only has two interrupts free (3 and 9). If I put a modem on 3 and an Ethernet board on 9, it works, but only by putting pccardd on irq 5, which doesn't really work. If I pull the Ethernet card, the whole machine hangs up when I try to access the net, presumably because pccardd hasn't found out about it. Have you tried setting the PCIC IRQ to 0, so that the driver polls instead? I have now. It ignored it and grabbed irq 5 anyway. Where is this described? I put it in my config file: # PCCARD (PCMCIA) support controller card0 device pcic0 at card? irq 0 device pcic1 at card? irq 0 Is that what you meant? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Usage of 'gdb' command in DDB
On Thursday, 1 July 1999 at 18:47:27 -0500, Stan Shkolnyy wrote: Hello All, Well, I entered 'gdb', then 'continue' and now I can debug the kernel remotely. How do I switch DDB back? Ctrl-Alt-Esc now causes DDB to contact the remote GDB instead of accepting input from me. A nuisance, isn't it? There's no documented way. I have this in my .gdbinit: define ddb set boothowto=0x8000 s end document ddb Switch back to ddb. end That works with -CURRENT. Don't count on it staying that way. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Major device number for firewire
Folks, I have been developing firewire (IEEE1394) device driver on FreeBSD and the driver is working quite stable. I would like to reserve major device number for firewire. P.S. The driver code can be obtained from following: ftp://ftp.uec.ac.jp/pub/firewire i...@koganei.wide.ad.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Xfree86 v 3.3.4
On Thu, 1 Jul 1999, Mark J. Taylor wrote: There is a Linux X server for the Voodoo Banshee, over at: http://developer.soundblaster.com/linux/ You might have some luck running it under the Linux emulator. I've never tried it, as I don't have a Banshee. Thanks! This appears to work pretty well, much better than I would expect a server for a different OS to work. I continue to be very impressed by the Linux emulation! The one problem I have with it is I can't get it to work with sysmouse. For the amount of time I spend using the text console on this box, I can live with killing and started moused manually. David To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Major device number for firewire
I assume you mean a major character device number only? You can have 127 (decimal). Any prediction on when you think this driver will be ready to bring into -current? It sounds quite promising! - Jordan Folks, I have been developing firewire (IEEE1394) device driver on FreeBSD and the driver is working quite stable. I would like to reserve major device number for firewire. P.S. The driver code can be obtained from following: ftp://ftp.uec.ac.jp/pub/firewire i...@koganei.wide.ad.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Major device number for firewire
From: Jordan K. Hubbard j...@zippy.cdrom.com Subject: Re: Major device number for firewire Date: Thu, 01 Jul 1999 19:49:29 -0700 Message-ID: 70335.930883...@zippy.cdrom.com jkh I assume you mean a major character device number only? You can jkh have 127 (decimal). jkh Thanks, I want to get just one character device. jkh Any prediction on when you think this driver will be ready to bring jkh into -current? It sounds quite promising! jkh I am now considering and designing firewire API as I said in FREENIX. When fixing API, I think it is appropriate to import current- . i...@koganei.wide.ad.jp To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
Would it be possible to have this code put up for www/ftp or something, so that anyone who is interested could have a look? Feel free, just don't ask me questions about it since I honestly don't have time right now to explain to many hundreds of people how to build this stuff. In a nutshell, use egcs to compile everything from the following list: turbovision 0.7, qt 1.42, libh 0.1 (see below). libh is the code in question and can be obtained from ftp://zippy.cdrom.com/pub/libh.tar.gz. It will work with either gmake or make. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
On Thu, Jul 01, 1999 at 03:18:00PM -0700, Ron 'The InSaNe One' Rosson wrote: On Thu, 01 Jul 1999, Matthew Jacob was heard blurting out: That being said... I've heard some of my ex-coworkers (who were all FreeBSD people when they worked here) come up to me in this impressed tone: You wouldn't believe how much easier it is to install RedHat!'. *sigh* I'm not bitching... just being loyal :) That's ridiculous. I've used both, and RedHat is not that much better, if at all. Just tried Redhat last month for the first time. Damn install is more confusing that FreeBSD.. Or maybe I just got accustomed to the freebsd install ;-) I have done installs on FreeBSD, Redhat, HP/UX, and Solaris and I have to say that Redhat is very confusing. FreeBSD does have it's warts but it is better than Redhat. HP/UX and Solaris also have their problems, just ask Nicole Harrington how she liked installing Solaris on an X86 box, but they are better than FreeBSD but not by as much as you would think. HP/UX install looks a lot like FreeBSD but not as limited as FreeBSD. The ability to have more than 2 buttons on the screen and too be able to backup is a major blessing. Josef -- Josef Grosch | FreeBSD 3.2 | Bay Area FreeBSD Users Group jgro...@ispchannel.com | www.freebsd.org |www.bafug.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
On Thu, 1 Jul 1999, Josef Grosch wrote: I have done installs on FreeBSD, Redhat, HP/UX, and Solaris and I have to say that Redhat is very confusing. FreeBSD does have it's warts but it is better than Redhat. HP/UX and Solaris also have their problems, just ask Nicole Harrington how she liked installing Solaris on an X86 box, but they are better than FreeBSD but not by as much as you would think. HP/UX install looks a lot like FreeBSD but not as limited as FreeBSD. The ability to have more than 2 buttons on the screen and too be able to backup is a major blessing. Uh, the Solaris packaging crap *is* a wart. It won't even work on a tarball.. The FreeBSD makefile mess could be extended to be about as flexible as the Solaris gunk. - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Lizard...
Feel free, just don't ask me questions about it since I honestly don't have time right now to explain to many hundreds of people how to build this stuff. In a nutshell, use egcs to compile everything from the following list: turbovision 0.7, qt 1.42, libh 0.1 (see below). libh is the code in question and can be obtained from ftp://zippy.cdrom.com/pub/libh.tar.gz. It will work with either gmake or make. FWIW it seems to want GNU make. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: pccard problems
In message 19990702105346.h87...@freebie.lemis.com Greg Lehey writes: : Is that what you meant? No. You need to set machdep.pccard.pcic_irq to be zero in your boot loader. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: UMAX scsi scanner on adaptec 1542 Card
In message 19990701163631.a20...@gras-varg.worldgate.com Greg Skafte writes: : I've got an adaptec 1542 card using aha driver and RELENG_3 detects it no : problems. OK. : If I use the adaptec on board utilities it finds my UMAX scanner no probs. OK. : when I try to boot the machine hangs just after the waiting for scsi to : settle message. Now I'm confused. Is this in -current where you are having the problems? : I've gabbed these as best as I can since the machine doesn't finish booting : so I can't grab a dmesg and I don't have a serial console. OK. Before going too far, please make sure that termination is currect. I've seen the timeout timeout ...not in timeout sequence when that was the case. I would have expected that from identical hardware with a RELENG_3 kernel, however. It is possible that something in the emulation layer in -current isn't working, or that -current's CAM does things a little faster than RELENG_3's CAM did, this exposing another bug in the aha driver. I didn't torture test it with anything except slow disks and a CDROM changer... Any other device will likely work or not work due entirely to chance. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: pccard problems
On Thursday, 1 July 1999 at 22:59:56 -0600, Warner Losh wrote: In message 19990702105346.h87...@freebie.lemis.com Greg Lehey writes: Is that what you meant? No. You need to set machdep.pccard.pcic_irq to be zero in your boot loader. Yes. Somebody else told me that. I tried it (and confirmed that show displayed it, and that it was spelt right), and it still grabbed irq 5. Just to make sure it wasn't lying, I pulled the Ethernet board. No message, and when I tried a ping, the machine locked up solid. This is 3.2-RELEASE; when I'm finished what I'm doing, I'll look for why it's not reacting correctly. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
