Re: what's going on after upgrade to svn-latest 9.
On Fri, Jun 21, 2013 at 01:17:31PM +0200, Wojciech Puchar wrote: i'm getting this on my computer. disk seems OK, smart shows nothing, dd reads whole partition without problem. no other errors from disk itself (AHCI timeout or so). started exactly after i rebooted with new kernel. everything unchanged. userland is in sync thanks for help g_vfs_done():ada0s3d.eli[WRITE(offset=30653186048, length=1048576)]error = 11 i've just tried recent 10.0-alpha4 on my laptop (normally running 8-stable) and start to see this shit as well. smart does not report anything wrong with my disks, and 8-stable never yielded anything like these messages, so it looks like some kind of false alarm. any clues? ./danfe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nvidia-driver-295.49 is highly unstable
On Tue, Jul 03, 2012 at 08:20:49PM -0700, Yuri wrote: On 05/27/2012 13:08, Alexey Dokuchaev wrote: Perhaps you can try asking on official nVidia FreeBSD forum: http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 I reported there 05-28-12, but got no response. That's very sad indeed. Do you know if there is a way to report a problem with NVidia? For example, is there a for example bugzilla or other bug reporting system for this? Unfortunately, I am not aware of such thing being exposed to the public. Forum is the closest thing that comes to mind. Individual developers can probably be contacted privately, but AFAICT they all read forum pretty regularly, so it makes little sense to spam them directly. In addition, I observe system hangup for a few seconds when running glxinfo. Also I observe Xorg freeze when I run nvidia-settings. So I have to run 285.05.09 from cvs instead. Do these issues persist with 295.59, latest long lived branch version? ./danfe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nvidia-driver-295.49 is highly unstable
On Sun, May 27, 2012 at 09:46:23AM -0700, Yuri wrote: After the recent system upgrade that brought nvidia-driver-295.49 my system began to malfunction. Xorg randomly freezes and gets to 100% CPU (in kde4), switching back from the black terminal takes 30 seconds, some windows don't repaint while windows effects are on, etc. Switching back to 295.05.09 from Feb 11, 2012 fixed the problem. Perhaps you can try asking on official nVidia FreeBSD forum: http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 Also, there seems to be new version available, 295.53. Can you try it out that report back to us if it remedies your problems? ./danfe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: No DRM kernel support for i830 ?
On Wed, Aug 11, 2004 at 12:20:11PM -0400, John Baldwin wrote: On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote: Hi there, Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES, there's currently evidence of support for i810/830 chips in FreeBSD, which (I suspect) is the probable reason why DRI is not enabled on my box (FreeBSD 5.2-CURRENT from yesterday, latest X.Org). I also found traces of i810/830 support in FDo CVS (http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/bsd/i830/), getting me to the fact that i8x0 files were removed from the BSD side, since they were not actually ported. (Unfinished? broken? unstable?) The i830 DRM stuff is ported in a branch of DRI, but it's not in DRI head because of a security problem with the code. Thanks. That's a good info to start with. May I ask you the details of security problem you've mentioned, or at least some pointer in this direction? Appropriate maillist and/or google reference would be fine, I guess. ./danfe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
No DRM kernel support for i830 ?
Hi there, Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES, there's currently evidence of support for i810/830 chips in FreeBSD, which (I suspect) is the probable reason why DRI is not enabled on my box (FreeBSD 5.2-CURRENT from yesterday, latest X.Org). I also found traces of i810/830 support in FDo CVS (http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/bsd/i830/), getting me to the fact that i8x0 files were removed from the BSD side, since they were not actually ported. (Unfinished? broken? unstable?) Googling also revealed that back in 2002, someone (namely, moto kawasaki [EMAIL PROTECTED]) was compiling FreeBSD's DRM with signs of i830 in it (https://lists.csociety.org/pipermail/freebsd-xfree86/2002-April/000189.html): %%% cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstr ict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fform at-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contri b/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../dev/drm/i830_dma.c ../../dev/drm/i830_dma.c: In function `i830_getbuf': ../../dev/drm/i830_dma.c:1506: `current' undeclared (first use in this function) ../../dev/drm/i830_dma.c:1506: (Each undeclared identifier is reported only once ../../dev/drm/i830_dma.c:1506: for each function it appears in.) *** Error Code 1 Stop in /usr/src/sys/compile/KAWASAKI %%% I would be most grateful to anyone that could shine a bit of light on current situation, or at least give authoritative and complete answer on whether I can or cannot use DRM/DRI on FreeBSD with i830 for today. On Eric's page (http://people.freebsd.org/~anholt/dri/) there's a TODO item that says Port the i810 driver. What is current status of this item? Is there anything I can help with? In case there something that can be done to hack it around and make it work, I'd really love to hear how. (Maybe there some untested or broken patches are floating around that one can make use of.) Thanks in advance. Any information/pointers are most welmome. ./danfe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Status of unionfs in -STABLE
Hi there, Recently I've began to consider making some use of unionfs in (semi-)production environment. Can someone aware of its current status in -STABLE comment a bit on this subject? Probably any information would be appreciated. Thanks so far, ./danfe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of unionfs in -STABLE
On Sun, Nov 09, 2003 at 03:24:21AM -0800, Kris Kennaway wrote: On Sun, Nov 09, 2003 at 02:54:59PM +0600, Alexey Dokuchaev wrote: Hi there, Recently I've began to consider making some use of unionfs in (semi-)production environment. Can someone aware of its current status in -STABLE comment a bit on this subject? Probably any information would be appreciated. Unchanged since the other times this topic has been discussed recently - see the archives for extensive discussion. (Summary: it's possible to avoid panicking if you carefully restrict the activities you do with unionfs, but expect panics and possible filesystem corruption while discovering those limits). Thanks, I'll investigate further. ./danfe ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Usenix 2002 FreeBSD Developer Summit III -- why no oggs?
On Sat, Sep 07, 2002 at 02:56:10AM -0700, Juli Mallett wrote: * De: Alexey Dokuchaev [EMAIL PROTECTED] [ Data: 2002-09-05 ] [ Subjecte: Usenix 2002 FreeBSD Developer Summit III -- why no oggs? ] Hi! I've read the notes as of 2 September, 2002 from the USENIX ATC 2002 FreeBSD Developer Summit, which were made available recently. As a very good addition to them, I suggest putting online some .oggs (or .mp3s) next time, with recorded speeches, just like guys from recent linux kernel summit did (ksmp3rep.sourceforge.net)? Sounds like a good idea to me. Opinions? ./danfe We've had MP3s and an MP3 stream for (at least) the last two summits, the problem comes down to one of enormous size. Uhm.. Still, is it available on the Net somewhere? Outbound traffic should not cost anything with any ISP, so essentially it sounds like big size is only my problem. :-)) ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Usenix 2002 FreeBSD Developer Summit III -- why no oggs?
Hi! I've read the notes as of 2 September, 2002 from the USENIX ATC 2002 FreeBSD Developer Summit, which were made available recently. As a very good addition to them, I suggest putting online some .oggs (or .mp3s) next time, with recorded speeches, just like guys from recent linux kernel summit did (ksmp3rep.sourceforge.net)? Sounds like a good idea to me. Opinions? ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sys/types.h or not sys/types.h? [Was: cvs commit: src/include grp.h]
On Tue, Feb 26, 2002 at 11:49:59AM +0300, Andrey A. Chernov wrote: On Mon, Feb 25, 2002 at 13:28:21 -0500, Garrett Wollman wrote: On Mon, 25 Feb 2002 17:23:53 +0300, Andrey A. Chernov [EMAIL PROTECTED] said: From IEEE P1003.1 Draft 7: You're looking at the wrong document. FreeBSD is very far from being ready to implement POSIX 2001 header files. POSIX 1990, which we do implement, requires sys/types.h almost everywhere. Well, if we are very far, it will be just little step to be closer. On other case we will be very far forever. If you mean hypotetical one-step transition mega-patch in future, it will breaks too many things at once to be something real. Is there any chance we will come anywhere close to POSIX 2001 at all? What about targeting to POSIX 1990/1996 *now* instead of aiming to the standard that would likely be rendered obsolete by the time we would reach it? Especially, we still appear to not have an agreement on standard changes introduced between 1996 and 2001. ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
THTTPD web server: problems with KQUEUE on FreeBSD 4.5-STABLE
Hello!
I've been using thttpd-2.22beta4 (www/thttpd) for about two weeks, and it
has been serving me greatly so far, except for one day...
I've been looking through http.log, and started to notice strange messages:
123.124.125.51 - - [13/Feb/2002:14:56:26 +0600] GET /123.124.210.52/top100.jpg
HTTP/1.1 200 0 http://123.124.125.52/; Mozilla/4.0 (compatible; MSIE 5.01; Wi
ndows NT 5.0)
123.124.125.51 - - [13/Feb/2002:14:56:29 +0600] GET /123.124.210.52/wolfenpsd_b
utton.gif HTTP/1.1 200 0 http://123.124.125.52/; Mozilla/4.0 (compatible; MSI
E 5.01; Windows NT 5.0)
123.124.125.51 - - [13/Feb/2002:14:56:40 +0600] GET /123.124.210.52/wolfstat_bu
tton.gif HTTP/1.1 200 0 http://123.124.125.52/; Mozilla/4.0 (compatible; MSIE
5.01; Windows NT 5.0)
123.124.125.51 - - [13/Feb/2002:14:56:40 +0600] GET /123.124.210.52/wolfmod.jpg
HTTP/1.1 200 0 http://123.124.125.52/; Mozilla/4.0 (compatible; MSIE 5.01; W
indows NT 5.0)
As you can notice, server says 200 OK, but returns contents of length
of 0! That's very strange. I've started to explore this issue, and found
out that things break around here (thttpd.c, lines 580-597):
/* Find the connections that need servicing. */
for ( ridx = 0; ridx num_ready; ++ridx )
{
c = (connecttab*) fdwatch_get_client_data( ridx );
if ( c == (connecttab*) 0 )
continue;
hc = c-hc;
if ( ! fdwatch_check_fd( hc-conn_fd ) ) {
/* Something went wrong. */ printf(!!\n);
clear_connection( c, tv ); }
else
switch ( c-conn_state )
{
case CNST_READING: handle_read( c, tv ); break;
case CNST_SENDING: handle_send( c, tv ); break;
case CNST_LINGERING: handle_linger( c, tv ); break;
}
}
I've marked with ! the error-place. More over, if, say,
server must serve 10 objects, and 2 will fail, there be 10 calls of
handle_read(), and only 8 of handle_send(), that is, that handle_read()
still gets called, even if fdwatch_check_fd() returned an error.
I decided not to run through all of fdwatch.c stuff, and neither through
FreeBSD sources, since I'm not too familiar with kqread mechanism. What
I did next, I've simply removed -DHAVE_KQUEUE from Makefile, and
recompiled the whole thing. The problem dissappreared! I haven't checked
the -DHAVE_POLL, but it seems that thttpd feels much better with
poll()'ing than with kqread()'ing (as seen in top(1)).
I still wonder, whether this problem occurs because of how thttpd does
things, or how FreeBSD implements kqueue stuff, however, I am not sure
that I will have enough time to dig deep into this. Right now I'm pretty
happy with the fact that I got thttpd working again, and those 200 0
messages are no longer in my logs. However, it is still an issue to
worry about, I believe, and I will be a lot more happy if my experience
helps either folks to find and fix some probable bugs (if any) in their
excellent software.
And one more question: out of kqread()/poll()/select() methods, which one
is more likely to perform better, both under normal server access, and
under heavy load? This is pretty important for me to choose the right
method of doing the non-blocking I/O, and, even in case I cannot use
kqueue, I am still curious which one is more preferrable for a webserver
to use, poll() or select() ?
Thank you very much for your time and concern.
--
Sincerely,
Alexey Dokuchaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: THTTPD web server: problems with KQUEUE on FreeBSD 4.5-STABLE
On Wed, Feb 13, 2002 at 02:29:30AM -0800, Kip Macy wrote: I still wonder, whether this problem occurs because of how thttpd does things, or how FreeBSD implements kqueue stuff, however, I am not sure I take it you don't have any logs for 4.4? You mean, webserver logs on FreeBSD 4.4? I don't have them, however, this problem did take place, and it persisted after upgrading to 4.5. Sad but true :( And one more question: out of kqread()/poll()/select() methods, which one is more likely to perform better, both under normal server access, and Under normal load it doesn't matter. Under heavy load there can be no comparison. see: http://www.kegel.com/dkftpbench/Poller_bench.html This excerpt is the FreeBSD relevant portion: With 1 active socket amongst 100, 1000, or 1 total sockets, waitAndDispatchEvents takes the following amount of wall-clock time, in microseconds (lower is faster): On a single processor 600Mhz Pentium-III with 512MB of memory, running FreeBSD 4.x-STABLE (results contributed by Jonathan Lemon): pipes10010001 3 select 54 -- - poll 50 55211559 35178 kqueue 8 88 8 (Note: Jonathan also varied the number of active pipes, and found that kqueue's time scaled linearly with that number, whereas poll's time scaled linearly with number of total pipes.) Hmm... It looks like kqueue is really the way to go... I think I should do a bit further investigation on this subject, since poll() does not satisfy me anymore :) Regards, Alexey D. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: THTTPD web server: problems with KQUEUE on FreeBSD 4.5-STABLE
On Wed, Feb 13, 2002 at 01:28:29PM +0300, Eugene L. Vorokov wrote:
I still wonder, whether this problem occurs because of how thttpd does
things, or how FreeBSD implements kqueue stuff, however, I am not sure
that I will have enough time to dig deep into this. Right now I'm pretty
happy with the fact that I got thttpd working again, and those 200 0
messages are no longer in my logs. However, it is still an issue to
worry about, I believe, and I will be a lot more happy if my experience
helps either folks to find and fix some probable bugs (if any) in their
excellent software.
Hm, there is no such thing as kqread() I think. There are kqueue() and
Oh, I merely meant that thttpd process was in kqread state in top(1) output.
Sorry for confusing you.
kevent(). You didn't show the piece of code that uses it, so it's hard
to say what the problem is. I recommend you to read jlemon's paper
OK, this is how kqueue mechanism is used in thttpd. This is from fdwatch.c
source file, starting at line 300 (I apologize for it's length):
#ifdef HAVE_KQUEUE
static struct kevent* kqevents;
static int nkqevents;
static int* kqrfdidx;
static int kq;
static int
kqueue_init( int nfiles )
{
kq = kqueue();
if ( kq == -1 )
return -1;
kqevents = (struct kevent*) malloc( sizeof(struct kevent) * nfiles );
kqrfdidx = (int*) malloc( sizeof(int) * nfiles );
if ( kqevents == (struct kevent*) 0 || kqrfdidx == (int*) 0 )
return -1;
(void) memset( kqevents, 0, sizeof(struct kevent) * nfiles );
(void) memset( kqrfdidx, 0, sizeof(int) * nfiles );
return 0;
}
static void
kqueue_add_fd( int fd, int rw )
{
kqevents[nkqevents].ident = fd;
kqevents[nkqevents].flags = EV_ADD;
switch ( rw )
{
case FDW_READ: kqevents[nkqevents].filter = EVFILT_READ; break;
case FDW_WRITE: kqevents[nkqevents].filter = EVFILT_WRITE; break;
default: break;
}
++nkqevents;
}
static void
kqueue_del_fd( int fd )
{
kqevents[nkqevents].ident = fd;
kqevents[nkqevents].flags = EV_DELETE;
switch ( fd_rw[fd] )
{
case FDW_READ: kqevents[nkqevents].filter = EVFILT_READ; break;
case FDW_WRITE: kqevents[nkqevents].filter = EVFILT_WRITE; break;
}
++nkqevents;
}
static int
kqueue_watch( long timeout_msecs )
{
int i, r;
if ( timeout_msecs == INFTIM )
r = kevent(
kq, kqevents, nkqevents, kqevents, nfiles, (struct timespec*) 0 );
else
{
struct timespec ts;
ts.tv_sec = timeout_msecs / 1000L;
ts.tv_nsec = ( timeout_msecs % 1000L ) * 100L;
r = kevent( kq, kqevents, nkqevents, kqevents, nfiles, ts );
}
nkqevents = 0;
if ( r == -1 )
return -1;
for ( i = 0; i r; ++i )
kqrfdidx[kqevents[i].ident] = i;
return r;
}
static int
kqueue_check_fd( int fd )
{
int ridx = kqrfdidx[fd];
if ( kqevents[ridx].ident != fd )
return 0;
if ( kqevents[ridx].flags EV_ERROR )
return 0;
switch ( fd_rw[fd] )
{
case FDW_READ: return kqevents[ridx].filter == EVFILT_READ;
case FDW_WRITE: return kqevents[ridx].filter == EVFILT_WRITE;
default: return 0;
}
}
static int
kqueue_get_fd( int ridx )
{
return kqevents[ridx].ident;
}
#else /* HAVE_KQUEUE */
In my previous mail I cited the code where error is often returned, and
that confuses the server. It was this one:
if ( ! fdwatch_check_fd( hc-conn_fd ) ) {
/* Something went wrong. */ printf(!!\n);
clear_connection( c, tv ); }
The fdwatch_check_fd() function is merely this one:
/* Check if a descriptor was ready. */
int
fdwatch_check_fd( int fd )
{
#ifdef HAVE_KQUEUE
return kqueue_check_fd( fd );
#else
# ifdef HAVE_POLL
return poll_check_fd( fd );
# else /* HAVE_POLL */
# ifdef HAVE_SELECT
return select_check_fd( fd );
# else /* HAVE_SELECT */
return 0;
# endif /* HAVE_SELECT */
# endif /* HAVE_POLL */
#endif /* HAVE_KQUEUE */
}
I really do hope that it will help someone to spot any possible problems
with this kqueue code.
at http://www.freebsd.org/~jlemon/kqueue.pdf to see how to you should
work with kqueue() and kevent().
As for performance, I can confirm that kqueue() functions is better
than select()/poll() at least in situations where we have to do non-blocking
i/o on some large number of fd's (say, several thousands), and actually
each time we see some activity only on small number of them (say,
several hundred). That's how ircd usually works, and system load goes
down significantly with kqueue() comparing to select().
WBR,
Alexey
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
THTTPD web server: problems with KQUEUE on FreeBSD 4.5-STABLE
- Forwarded message from Jef Poskanzer [EMAIL PROTECTED] - Date: Wed, 13 Feb 2002 08:44:55 -0800 From: Jef Poskanzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [THTTPD] THTTPD web server: problems with KQUEUE on FreeBSD 4.5-STABLE I ran into this exact problem last week, in FreeBSD 4.5-RC1. My workaround was also the same - undefine HAVE_KQUEUE. I haven't tried to debug yet. I have *not* seen the problem in FreeBSD 4.4. The only ' 200 0 ' that appears in the logs of my 4.4 machine was for a HEAD request, which is correct. However that machine doesn't get a whole lot of traffic, less than 100 requests per week, so this is not definitive. --- Jef Jef Poskanzer [EMAIL PROTECTED] http://www.acme.com/jef/ - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Some PCI-related programming things
On Wed, 21 Mar 2001, Mike Smith wrote: Hey, that's not fair :-) I'd like to know how to do things the rigth way. You'll need to tell us what it is that you're actually doing, then, since it's hard to guess from a tiny snippet like that. 8) Well, but if you didn't know, how could you tell that I'm doing something very wrong then? :-) Because dinking with PCI configuration space is usually the wrong thing to do from userland. So what about pciconf(8)? I was porting (that is, it's not mine) some linux code that walks thru PCI bus, searches for a particular device, and when it finds any, figures out their parameters and fills some structures. This code is used, actually, in char device driver. Mm, so what's it doing in userspace? 8) Did I say I'm doing it from userspace?! If I did (too lazy to dig into sent-mail), I beg your pardon :) -- Rgs, Alexey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some PCI-related programming things
On Wed, 21 Mar 2001, Mike Smith wrote: This code is used, actually, in char device driver. Mm, so what's it doing in userspace? 8) Did I say I'm doing it from userspace?! If I did (too lazy to dig into sent-mail), I beg your pardon :) Your FreeBSD sample involved making an ioctl call, so it must have been from userspace. Is anything wrong with using ioctl calls from device driver? -- WBR, Alexey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some PCI-related programming things
On Wed, 21 Mar 2001, Mike Smith wrote: Did I say I'm doing it from userspace?! If I did (too lazy to dig into sent-mail), I beg your pardon :) Your FreeBSD sample involved making an ioctl call, so it must have been from userspace. Is anything wrong with using ioctl calls from device driver? Perhaps a more polite answer is called for. 8) Ioctls allow user processes to make function calls within a device driver; they are a mechanism for exporting functionality from a device driver out into userspace. I know that, of course. You don't call them from other device drivers, no. There are exported interfaces inside the kernel for doing this, and you will understand everything much better if you go look at a simple FreeBSD PCI device driver, particularly the _probe and _attach functions. Look, I am *not* coding a PCI driver. I have looked at various examples in sound/pci/ and I know what PCI device driver should look like. What I am doing is *porting* linux *character* device driver to FreeBSD. That is, if original version called all that linuxish pci_whatever() functions, I have to provide the same functionality under FreeBSD. I didn't know how to do this. What I did was, I said man pci, from there I figured out about pciconf utility. I took a look at it, and thought, ok, this must be the way I have to go for under FreeBSD. At first, I thought I calling ioctl's from kernel space is probably at least weird idea (if not to call it bad). But I was unable to find any PCI-related doc which would answer my questions. Trust me, if I wanted to code a PCI dev driver, I would certainly not do this. I have a code to take a look at, and I only ask questions when I seem to fail to comprehend going of things from the code. It's not written anywhere I can't use ioctl from char device driver. Or is it? -- Me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some PCI-related programming things
On Wed, 21 Mar 2001, Mike Smith wrote: Ioctls allow user processes to make function calls within a device driver; they are a mechanism for exporting functionality from a device driver out into userspace. I know that, of course. This wasn't clear from your example. Oh, OK, sorry... You don't call them from other device drivers, no. There are exported interfaces inside the kernel for doing this, and you will understand everything much better if you go look at a simple FreeBSD PCI device driver, particularly the _probe and _attach functions. Look, I am *not* coding a PCI driver. I have looked at various examples in sound/pci/ and I know what PCI device driver should look like. Ok. So why are you attempting to manipulate PCI configuration space? What I am doing is *porting* linux *character* device driver to FreeBSD. A device driver still talks to hardware, and by the sound of it, your hardware is PCI hardware. Since you won't actually tell me what it is you're actually doing with any sort of useful level of detail, it is very hard to give you useful answers. That is, if original version called all that linuxish pci_whatever() functions, I have to provide the same functionality under FreeBSD. I didn't know how to do this. What I did was, I said man pci, from there I figured out about pciconf utility. I took a look at it, and thought, ok, this must be the way I have to go for under FreeBSD. You're writing a device driver. Look at other device drivers that behave similarly. Whether the driver has a character interface or not is more or less irrelevant at this stage. 8) OK, I'll do. Frankly, device driver is easy part, I would eventually figure it out. What makes me worry is that VM staff... Trust me, if I wanted to code a PCI dev driver, I would certainly not do this. I have a code to take a look at, and I only ask questions when I seem to fail to comprehend going of things from the code. It's not written anywhere I can't use ioctl from char device driver. Or is it? Firstly, there is no such thing as "a character device driver". Secondly, if it's running inside the kernel, it doesn't matter what it is; you don't make ioctl calls (exception: ABI shims). OK, I understand. Thanks for explanations, and sorry for somewhat lame questions. The rest is probably going to be rather obvious, given your information + tons of source code I will surely look at :) -- Me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some PCI-related programming things
On Sun, 18 Mar 2001, Mike Smith wrote: Hello there, Under linux, PCI stuff is generally done thru set of pci* functions, while under FreeBSD there are ioctls provided by pci driver. I've been doing some code migration from linux to FreeBSD, and got thru most of it, except for things like this one: You are probably doing something very wrong here, but rather than try to convince you to do it, right, I'll just answer your question. 8) Hey, that's not fair :-) I'd like to know how to do things the rigth way. 10x -- Alexey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Some PCI-related programming things
Hello there, Under linux, PCI stuff is generally done thru set of pci* functions, while under FreeBSD there are ioctls provided by pci driver. I've been doing some code migration from linux to FreeBSD, and got thru most of it, except for things like this one: code ostype="linux" . . . pcibios_read_config_dword(bus_id, func_id, PCI_BASE_ADDRESS_0, addr_0); addr_0 = PCI_BASE_ADDRESS_IO_MASK; pcibios_read_config_dword(bus_id, func_id, PCI_BASE_ADDRESS_1, addr_1); addr_1 = PCI_BASE_ADDRESS_MEM_MASK; . . . /code I am not quite sure how to code the same thing under FreeBSD, particulary: pi.pi_width = 4; pi.pi_reg = WHAT DO I PUT HERE? ioctl(fd, PCIOCREAD, pi); Could anyone give me an example for both addr_0 and addr_1 (that is, translation of the linux code I cited above?) I will really appreciate any help with regard to this. Thanks in advance. -- Alexey. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Mon, 12 Mar 2001, Jose M. Alcaide wrote:
Alexey Dokuchaev wrote:
Actually, there's one more question I have about XFree-4. IIUC, core GL
libs, such as libGL.so, libOSMesa.so, etc are included in XFree 4.0.2 core
distribution. So how come that lots of applications still have Mesa-3.2
in their dependencies?
The Mesa bits included in XFree86 4.0.2 are a subset of the Mesa-3.2 port.
If you have XFree86 4.0.2 installed, you should define XFREE86_VERSION=4
in /etc/make.conf; then, the Mesa 3.2 port only installs the files not
included in XFree-4. Also, the ports which use the Xpm library do not
depend on the xpm port (XFree-4 includes Xpm).
Still there are some ports which have not been adapted to the
XFREE86_VERSION mechanism; one of these is x11-toolkits/xaw3d: its
Makefile checks for the existence of ${X11BASE}/XFree86 in order to
find out what XFree86 version is installed.
Thanks a lot for your response.
//danfe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Porting NVidia linux kernel modules to FreeBSD
Hello! I'm quite interested in having true 3D hardware acceleration on my ASUS AGP-V3800Magic video card based on TNT2 M64 chip, while running XFree86-4.0.2 on FreeBSD 4.2-STABLE. I've been searching USENET, mail-archives, web, and all I was able to find was: * information on www.nvidia.com about binary XFree modules and kernel module (for linux only) * the source for linux kernel * binary XFree modules (replacing xfree's native 'nv' - 'nvidia') * people saying that there's some undergoing work about porting linux source to FreeBSD so it's possible to use proprietary nvidia's modules for XFree (oh gee, how happy I am with their module architecture) So, my question is, what's the current status of this initiative? Is there any pre-alphas or whatever I might try already? I will appreciate any information with regard to this subject. 10x. ./danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Sun, 11 Mar 2001, Jordan Hubbard wrote: 3D acceleration (or the lack thereof) is supposed to be one of the reasons why XFree 336 is still the standard version delivered for FreeBSD. It is, at least for me. I've been waiting for XFree86 4.0.x to come up to the same FPS performance numbers since it came out. So, are you saying that 3.3.6 performs better than 4.0.2? If this is true I might dump 4.0.2 and go for 3.3.6 (luckily there's server with ttf support builtin). -- WBR, Alexey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Sun, 11 Mar 2001, Jordan Hubbard wrote: So, are you saying that 3.3.6 performs better than 4.0.2? If this is true Absolutely. At least 2X the frame rate using the same OpenGL app in each case. But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, right, like it would be in case of nvidia cards? Contrary, it cant' be *that* bad if I carry out these test with card that fully supports DRI. right? //danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, No. Meaning, 3.3.6 + utah_glx outperforms by a factor of two 4.0.2 + DRI?! - danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Mon, 12 Mar 2001, Alexey Dokuchaev wrote: But, this is when using hw accel on 3.3.6 vs. software "accel" on 4.0.2, No. Meaning, 3.3.6 + utah_glx outperforms by a factor of two 4.0.2 + DRI?! Or, even better, 4.0.2 + "suppose-we-managed-to-port-it nvidia kernel module" + nvidia binary 'nvidia' replacement module for XFree-4's 'nv' driver? I mean, will 336/utah be better?? //danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting NVidia linux kernel modules to FreeBSD
On Mon, 12 Mar 2001, Daniel O'Connor wrote: On 12-Mar-01 Alexey Dokuchaev wrote: That's what I thought, but Jordan's email really made me doubt that my vision of things is correct. Particulary, I don't quite understand this one: Statement #1: Utah-GLX doesn't direct render Statement #2: From man nv(4) of XFree-4.0.2- "The driver is fully accelerated, and provides support..." This means 'in 2D'. Oh, OK, got it now. 10x. ./me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SecureBSD
On Fri, 29 Dec 2000, Wes Peters wrote: You may want to look at http://www.trustedbsd.org/ as well. It is provided under the Berkeley license, and much of what is developed there will be folded into FreeBSD as time permits. The primary author of TrustedBSD is Robert Watson, who is now a FreeBSD Core Team member as well. Actually, TrustedBSD seems to be in very early stages of development. For now, I've decided that the best solution for me would be `spy' KLD (www.freebsd.org - projects - SPY). //danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SecureBSD
Hello! Some pretty good time ago, I accidentally found SecureBSD (www.securebsd.org), which is a security patch for 3.4-REL and 4.0-REL. I kept a note about this site, and that's about it. Recently, reviewing my ~/cool.lynx file, I've found this site again. Interested, I dloaded it (4.0 version) and tried to apply it to my pretty recent 4.2-STABLE. Not surprisingly, it didn't apply, there were lots of rejects. I looked at rejected code, and it seems that it can be fixed easily. I've already wrote a perl script that would help me fixing all the patches :) The point of this letter is, whether SecureBSD worth trying or not? Maybe, even if I manage to correctly apply all the patches, it still would not work? It seems like really useful and cool thing, but I've hardly seen anyone using or even mentioning it. Will it help me make more secure server than using standard FreeBSD methods? Of course, I speak from 4.2-STABLE user/hacker position. Opinions? Thought? Everything will be appreciated :) Thanks. \\danfe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Block vs. frag sizes in newfs
Hello!
Sorry for x-posting: I've heard somewhere that not too many ppl actually
read fs...
AFAIR, there was a conversation going on concerning ${SUBJ}. I remember
some thougths that -b = -f is sort of optimum, things like that...
Or, why 8192/1024 are installation defaults?..
What it the truth behind all this? I'm intereted in any opinion.
Thanks.
--
DAN Fe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
