Re: Freebsd 5.3 hangs under heavy load????
Amandeep Pannu wrote: Hi all, I have two Seagate SCSI drives 36GB and 8GB RAM and installed 5.3-REL with PAE and SMP support. Now the problem arises that the system hangs under heavy load and there are no error messages nothing. I have to hard boot it everytime it hangs. PAE must have something to do with this. i have similar reports from fellow admins (they run large free mail service): machines with lots (4+ gigs) of memory, 5.3R, SMP and PAE enabled just refused to cooperate, freezing and crashing all the way under load. sadly, having no time to dive into gory details, they just installed Linux on those and all has been going well since that... the point is: PAE and large memory configurations in general need more testing. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 smime.p7s Description: S/MIME Cryptographic Signature
Re: Freebsd 5.3 hangs under heavy load????
Hi all, I have two Seagate SCSI drives 36GB and 8GB RAM and installed 5.3-REL with PAE and SMP support. Now the problem arises that the system hangs under heavy load and there are no error messages nothing. I have to hard boot it everytime it hangs. Any ideas what is going on. It is a Supermicro MB. 2GB PC2100 DDR266 ECC/Reg Intel Xeon 2.4 GHz 533FSB Thanks in advance. A ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Freebsd 5.3 problem
Hi Jason > On 03/14/05 15:34:59, Amandeep Pannu wrote: >> Hi Kris, >> >> I had this problem before and I changed the MB and the memory and >> today it >> did the same thing it did before. >> memtest doesnt give any errors. >> >> Thanks >> A >> >> > > Memtest86 right? There is another that you run in an os like any other > program. Did you leave memtest86 running over night or the weekend? > How are your temps under load? Do you use a ups? The system is in Co-lo so no power problems. Yes memtest86. I did run for the whole weekend. No errors. I need to check the loads if the system comes up. it just shut down. It gave me this error message. Mar 15 03:52:14 d03 kernel: amr0: bad slot 17 completed I read under many lists that the amr drives dies under heavy loads. But what about the system not going through post and giving RAM R/W failure. I am confused!!:( > > >> > On Mon, Mar 14, 2005 at 12:23:59PM -0800, Amandeep Pannu wrote: >> >> >> >> HI all, >> >> >> >> I am running FreeBSd 5.3-REL >> >> >> >> Today my system simply locked up. There was no error sent to >> console, >> >> to >> >> any logs, nor the monitor screen. It was totally unresponsive to >> >> network, >> >> serial console, or keyboard. After 4 power-cycles, we were unable >> to >> >> get >> >> past the BIOS as it was reporting "RAM R/W error". I have a >> screen >> shot >> >> of this from the serial port console, but it is the same as the >> one >> from >> >> before. If I hit the "F1" >> > >> > Looks like hardware failure. >> > >> > Kris >> > >> > -- >> > In God we Trust -- all others must submit an X.509 certificate. >> > -- Charles Forsythe <[EMAIL PROTECTED]> >> > ___ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to "freebsd-hackers- >> [EMAIL PROTECTED]" >> > >> >> >> -- >> Amandeep.S >> [EMAIL PROTECTED] >> http://aman.chamkila.org >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers- >> [EMAIL PROTECTED]" >> >> >> >> > > > -- Amandeep.S [EMAIL PROTECTED] http://aman.chamkila.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: poll or select for ppi?
In message: <[EMAIL PROTECTED]>
Matt Kory <[EMAIL PROTECTED]> writes:
: Is it possible to use poll or select to detect a change in the status
: bits of the parallel port? I tried something like this, and took bits
: 5 and 6 of the status register low and nothing seemed to happen. Is
: what I am trying to do even possible, or I am supposed to take a
: certain bit low to cause a read event? Any help is appreciated.
:
: int ppi_fd;
: char port[] = "/dev/ppi0";
: ppi_fd = open(port, O_RDWR);
:
: fd_set rfds;
: struct timeval tv;
: tv.tv_sec = 0;
: tv.tv_usec = 10;
:
: while(1) {
: FD_ZERO( &rfds );
: FD_SET( ppi_fd, &rfds );
: if ( select(1, &rfds, NULL, NULL, &tv) ) {
: printf("hi\n");
: }
: }
With the driver, as written: No. You can't poll(2). You can ask the
device often if something has changed yet.
However, it would be relatively simple to add a read channel and poll
support. I've written several custom drivers that do things based on
parallel port interrupts... Such drivers aren't that hard.
Warner
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory leak in inflate.c
On Tue, Mar 15, 2005 at 09:42:07PM +0100, Marc Olzheim wrote: > > Thanks. Could someone generate the patch as I dont have the latest > > FreeBSD source checked out. > > Hmm, there seem to be more possible leaks, as the code has been > literally copied from /usr/src/gnu/usr.bin/gzip/, including the define > of PKZIP_BUG_WORKAROUND. Have you checked all possible problems, or did > you just stumble onto this one ? Ah, never mind, that PKZIP_BUG_WORKAROUND part seems to be ok. Here it is. Marc --- kern/inflate.c Tue Mar 15 21:46:14 2005 +++ kern/inflate.c Tue Mar 15 21:46:22 2005 @@ -956,14 +956,15 @@ return i; /* incomplete code set */ #endif } + /* decompress until an end-of-block code */ - if (inflate_codes(glbl, tl, td, bl, bd)) - return 1; + i = (inflate_codes(glbl, tl, td, bl, bd)) ? 1 : 0; /* free the decoding tables, return */ huft_free(glbl, tl); huft_free(glbl, td); - return 0; + + return i; } /* decompress an inflated block */ pgpehXhX6L819.pgp Description: PGP signature
Re: memory leak in inflate.c
On Tue, Mar 15, 2005 at 12:15:11PM -0800, [EMAIL PROTECTED] wrote: > Thanks. Could someone generate the patch as I dont have the latest > FreeBSD source checked out. Hmm, there seem to be more possible leaks, as the code has been literally copied from /usr/src/gnu/usr.bin/gzip/, including the define of PKZIP_BUG_WORKAROUND. Have you checked all possible problems, or did you just stumble onto this one ? Marc pgpmtFKH4ORVV.pgp Description: PGP signature
Re: threads question
On Tuesday 15 March 2005 12:02 pm, you wrote: > On Tue, 15 Mar 2005, Michael C. Shultz wrote: > [cut] > > > The answer is probably something like what you just said, scope > > being lost when making the call to a shared library. Why is it ok > > going to a static library but not a shared though? > > There is probably a race condition, so your code will work *some* of > the time unless you prevent the race condition. I don't have an > answer to your question, but I don't think it is a valid question. > The scope of "*priority" can remain valid or invalid for random > reasons and thus may work some of the time, but the only way to > guarantee that it works all the time is to eliminate the race > condition by making sure that *property is valid though the life of > the thread. > > -Zera Hmmm, should I'll try making "property" global then passing a copy of it to each thread? I think that will guarantee it stays valid. -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: memory leak in inflate.c
Thanks. Could someone generate the patch as I dont have the latest FreeBSD source checked out. br vijay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Marc Olzheim Sent: Tuesday, March 15, 2005 11:31 AM To: Marco Molteni Cc: freebsd-hackers@freebsd.org Subject: Re: memory leak in inflate.c On Mon, Mar 14, 2005 at 09:43:52PM +0100, Marco Molteni wrote: > On Mon, 14 Mar 2005 <[EMAIL PROTECTED]> wrote: > > Hi, I am trying to debug a memory leak in executing gzipped binaries ^^ > > when the parameter list is too long. The function in question is > > inflate_dynamic(). > > _If_ I remember correctly, if inflate_dynamic() returns a non-zero > code it means that the decompression failed and the program itself > quits right away, no memory leak. Or am I missing something? Your missing something: /usr/src/sys/kern/inflate.c ;-) Looks like a good patch to me. Marc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threads question
On Tue, 15 Mar 2005, Michael C. Shultz wrote: [cut] > The answer is probably something like what you just said, scope being > lost when making the call to a shared library. Why is it ok going to a > static library but not a shared though? There is probably a race condition, so your code will work *some* of the time unless you prevent the race condition. I don't have an answer to your question, but I don't think it is a valid question. The scope of "*priority" can remain valid or invalid for random reasons and thus may work some of the time, but the only way to guarantee that it works all the time is to eliminate the race condition by making sure that *property is valid though the life of the thread. -Zera ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threads question
On Tuesday 15 March 2005 10:19 am, Daniel Eischen wrote: > On Tue, 15 Mar 2005, Michael C. Shultz wrote: > > Daniel, sorry to bother you again but I ran into something that is > > either a bug or I am missing a vital piece of information > > somewhere. Here is the situation: > > > > this works perfectly because I moved MGPMrUpgrade into > > the same .c file so it would be a static function: > > > > structProperty* property; > > pthread_t threads[NTHREADS]; > > pthread_create( &threads[0], NULL, zzMGPMrUpgrade, property ); > > > > When I use MGPMrUpgrade from a shared library the function runs > > yet property isn't being passed! > > > > I remember from assembly days that there were some stack tricks to > > be done when making calls to a shared library in order to pass the > > parameters, I forget what they are (been ages since I did assembly > > programming) but anyways it seems like with gcc passing the args > > through the stack to a function in a shared library isn't being > > handled correctly. Am I missing something obvious? > > I don't know. You have to be sure that whatever property > points to stays valid for the life of the thread (or at > least as long as it is used). I have to reply to you through freebsd-hackers@freebsd.org because your blocking verizon's smtp. I just converted everything to static libraries and now pthread_create is working just fine. The answer is probably something like what you just said, scope being lost when making the call to a shared library. Why is it ok going to a static library but not a shared though? In a few days, when there is time, I will write an assembly routine with nasm to use pthread_create and pass my structProperty argument to a shared library with it, this way I can see just exactly what is being passed through the stack. Then hopefully I can find some C/assembly guru who can look at it and teach me how to do it with C. Messing with and examining stacks in C is way beyond my present abilities. (I'm a C newbie) -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory leak in inflate.c
On Mon, Mar 14, 2005 at 09:43:52PM +0100, Marco Molteni wrote: > On Mon, 14 Mar 2005 <[EMAIL PROTECTED]> wrote: > > Hi, I am trying to debug a memory leak in executing gzipped binaries ^^ > > when the parameter list is too long. The function in question is > > inflate_dynamic(). > > _If_ I remember correctly, if inflate_dynamic() returns a non-zero > code it means that the decompression failed and the program itself > quits right away, no memory leak. Or am I missing something? Your missing something: /usr/src/sys/kern/inflate.c ;-) Looks like a good patch to me. Marc pgpGxhud3Bc5I.pgp Description: PGP signature
Re: threads question
On Tue, 15 Mar 2005, Michael C. Shultz wrote: > > Daniel, sorry to bother you again but I ran into something that is > either a bug or I am missing a vital piece of information somewhere. > Here is the situation: > > this works perfectly because I moved MGPMrUpgrade into > the same .c file so it would be a static function: > > structProperty* property; > pthread_t threads[NTHREADS]; > pthread_create( &threads[0], NULL, zzMGPMrUpgrade, property ); > > When I use MGPMrUpgrade from a shared library the function runs > yet property isn't being passed! > > I remember from assembly days that there were some stack tricks to be > done when making calls to a shared library in order to pass the > parameters, I forget what they are (been ages since I did assembly > programming) but anyways it seems like with gcc passing the args > through the stack to a function in a shared library isn't being handled > correctly. Am I missing something obvious? I don't know. You have to be sure that whatever property points to stays valid for the life of the thread (or at least as long as it is used). -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threads question
On Monday 14 March 2005 08:57 pm, Daniel Eischen wrote: > On Mon, 14 Mar 2005, Michael C. Shultz wrote: > > Hi, I've just reached a point in a program I'm writing where I'd > > like to do threading. > > > > When I try to start a thread like this: > > > > pthread_create(&thread, &attr, MGPMrUpgrade, property ); > > &property > > You should compile with -Wall and get rid of any warnings. > > > where property is a structure of many variables it doesn't get > > passed to the function. If I do this: > > > > pthread_create(&thread, &attr, MGPMrUpgrade( &property ), NULL ); > > That looks like it will actuall call MGPMrUpgrade() and use its > return value as the function pointer. > > > It works, but just seems wrong. > > > > Can anyone point me to a source file, preferably in /usr/src > > somewhere that passes a structure to a function being run as a > > thread so I may study the proper way to do this? > > src/lib/libpthread/test/sem_d.c > src/lib/libpthread/test/mutex_d.c > src/lib/libpthread/test/sigwait_d.c > > I'd suggest getting Butenhof's "Programming with POSIX Threads" book. Daniel, sorry to bother you again but I ran into something that is either a bug or I am missing a vital piece of information somewhere. Here is the situation: this works perfectly because I moved MGPMrUpgrade into the same .c file so it would be a static function: structProperty* property; pthread_t threads[NTHREADS]; pthread_create( &threads[0], NULL, zzMGPMrUpgrade, property ); When I use MGPMrUpgrade from a shared library the function runs yet property isn't being passed! I remember from assembly days that there were some stack tricks to be done when making calls to a shared library in order to pass the parameters, I forget what they are (been ages since I did assembly programming) but anyways it seems like with gcc passing the args through the stack to a function in a shared library isn't being handled correctly. Am I missing something obvious? -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI initiator driver beta version, testers wanted
In the last episode (Mar 15), Scott Long said: > Danny Braniss wrote: > >things are looking much better 2day, got tag queuing to work, and > >now it's much faster. Q: how can the driver tell the cam to enable > >queing (ie: camcontrol tag 0:0:0 -Nn), and > > case XPT_PATH_INQ: > cpi->hba_inquiry = PI_TAG_ABLE > > >Q: is there a rule of thumb as to how many tag'ed? > > When you call cam_sim_alloc(), there are arguments for how many > concurrent tagged and untagged transactions the driver can handle. I > don't know how tags work in iscsi, so I can't say what a good number > is here. Note that tag management is left completely up to the > driver; CAM will tell you whether or not to use a tag for a > particular CCB, but it's up to the driver to assign and track the tag > number. I would guess that tags would be even more useful for iscsi than direct-attached scsi, due to the extra latency. The more the better. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI initiator driver beta version, testers wanted
Danny Braniss wrote: things are looking much better 2day, got tag queuing to work, and now it's much faster. Q: how can the driver tell the cam to enable queing (ie: camcontrol tag 0:0:0 -Nn), and case XPT_PATH_INQ: cpi->hba_inquiry = PI_TAG_ABLE Q: is there a rule of thumb as to how many tag'ed? When you call cam_sim_alloc(), there are arguments for how many concurrent tagged and untagged transactions the driver can handle. I don't know how tags work in iscsi, so I can't say what a good number is here. Note that tag management is left completely up to the driver; CAM will tell you whether or not to use a tag for a particular CCB, but it's up to the driver to assign and track the tag number. thanks, danny PS: soon there will be a new beta, any news with the old one? Sorry, I haven't had much time to review the old one yet. Sounds like you're making really good progress, though. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: some bugs in the kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 14 Mar 2005, Ted Unangst wrote: These bugs were found using the Coverity Prevent static analysis tool. Memory Leak File: usr/home/tedu/src/sys/geom/geom_bsd.c Function: g_bsd_ioctl Returning at line 378 leaks the just allocated 'label'. Buffer Overrun File: usr/home/tedu/src/sys/dev/hptmv/gui_lib.c Function: hpt_default_ioctl At line 1262, the loop bound of MAX_ARRAY_PER_VBUS is defined to be twice the size of pVDevice (MAX_VDEVICE_PER_VBUS). Buffer Overrun File: usr/home/tedu/src/sys/dev/hptmv/entry.c Function: SetInquiryData At line 2660, loop bound of 20 is greater than size of VendorID. Memory Leak File: usr/home/tedu/src/sys/dev/pci/pci.c Function: pci_suspend If bus_generic_suspend fails at line 1061, 'devlist' is leaked. Use After Free, Memory Corruption File: usr/home/tedu/src/sys/dev/mlx/mlx_pci.c Function: mlx_pci_attach Calling mlx_free on error at line 218 is dangerous, since mlx_attach also called it. Eventually this will double free assorted bus resources. NULL pointer dereference File: usr/home/tedu/src/sys/pci/if_ti.c Function: ti_setmulti malloc return at 1628 is not checked against NULL. -- Ted Unangst www.coverity.com Coverity, Inc. Pretty cool, thanks.. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCNuYQsmFQuvffl58RAqkEAJ41uvoxxZOLoclnAO15d+rlewIXOACeOyRg PJ48VXqgInEjY3FDOv42Aco= =RkCW -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
some bugs in the kernel
These bugs were found using the Coverity Prevent static analysis tool. Memory Leak File: usr/home/tedu/src/sys/geom/geom_bsd.c Function: g_bsd_ioctl Returning at line 378 leaks the just allocated 'label'. Buffer Overrun File: usr/home/tedu/src/sys/dev/hptmv/gui_lib.c Function: hpt_default_ioctl At line 1262, the loop bound of MAX_ARRAY_PER_VBUS is defined to be twice the size of pVDevice (MAX_VDEVICE_PER_VBUS). Buffer Overrun File: usr/home/tedu/src/sys/dev/hptmv/entry.c Function: SetInquiryData At line 2660, loop bound of 20 is greater than size of VendorID. Memory Leak File: usr/home/tedu/src/sys/dev/pci/pci.c Function: pci_suspend If bus_generic_suspend fails at line 1061, 'devlist' is leaked. Use After Free, Memory Corruption File: usr/home/tedu/src/sys/dev/mlx/mlx_pci.c Function: mlx_pci_attach Calling mlx_free on error at line 218 is dangerous, since mlx_attach also called it. Eventually this will double free assorted bus resources. NULL pointer dereference File: usr/home/tedu/src/sys/pci/if_ti.c Function: ti_setmulti malloc return at 1628 is not checked against NULL. -- Ted Unangst www.coverity.com Coverity, Inc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvsup can't work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 14 Mar 2005, Michael C. Shultz wrote: On Monday 14 March 2005 06:33 pm, wanakahalugi wrote: hi all, I installed FreeBSD5.3REL on my PC, and I want to update the source tree and ports collection using cvsup. To do that I copy the stable-supfile to /etc directory and set its default host tag to the nearest mirror, and also set only the ports that I want to update to save bandwith. Everything is work fine except when I run the command # cvsup /etc/stable-supfile the response from the mirror server is like this : [EMAIL PROTECTED] root]# cvsup /etc/stable-supfile Cannot connect to cvsup.id.FreeBSD.org: Connection refused Will retry at 09:31:28 I use netstat to look what happen inside those error message, and I found this one : [EMAIL PROTECTED] cakra]$ netstat Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 192.100.40.14.53875 mirror.cbn.net.i.cvsup SYN_SENT The PC never ESTABLISHED the connection to the server it's only do the SYN_SENT. Why it happen? Is cvsup using certain ports so I can make some proper change on my firewall? It uses port 5999 see /etc/services -Mike No I think his problem is using the server he has specified "cvsup.id.FreeBSD.org" change ".id." to a different country instead. sed s/\.id\./\.us\./g Since there is only one server listed in that country more then likely H NO "Its dead!" Try another. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF7DF979F iD8DBQFCNt7/smFQuvffl58RAiqnAJ97gomWEFWg8ENT5ujG1Xf3qWmsNwCeK44o P8wUJnwFtvMfy2COGqbZPig= =61Jl -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is this GEOM thing?
Stas Myasnikov <[EMAIL PROTECTED]> writes: > Can anyone tell me what is GEOM basically? I know that there's geom@, > but I think it's about concrete realisation. It's an abstraction layer for dealing with disk transformations (partitioning, RAID, encryption etc.) > I know that it's a layer between device drivers and devfs, but do > I really need it on my home PC? Should I include it in the KERNEL? GEOM is not optional. Your computer would be unable to boot without it. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
What is this GEOM thing?
Hello, hackers. Can anyone tell me what is GEOM basically? I know that there's geom@, but I think it's about concrete realisation. I know that it's a layer between device drivers and devfs, but do I really need it on my home PC? Should I include it in the KERNEL? Bye. --- http://www.flirt.by - белорусский сервер знакомств. Десятки тысяч белорусских анкет с фотографиями. Сотни парней и девушек готовы к online-общению прямо сейчас. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: iSCSI initiator driver beta version, testers wanted
things are looking much better 2day, got tag queuing to work, and now it's much faster. Q: how can the driver tell the cam to enable queing (ie: camcontrol tag 0:0:0 -Nn), and Q: is there a rule of thumb as to how many tag'ed? thanks, danny PS: soon there will be a new beta, any news with the old one? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
