Atomic operations across multiple processors
atomic(9) states: The current set of atomic operations do not necessarily guarantee atomic- ity across multiple processors. ... On the i386 architecture, the cache coherency model requires that the hardware perform this task, thus the atomic operations are atomic across multiple processors. On the ia64 architecture, coherency is only guaranteed for pages that are configured to using a caching policy of either uncached or write back. Unfortunately, this doesn't document the behaviour for other architectures - this makes it difficult to write portable code. For the ia64, the statement isn't especially helpful because there's no indication of what caching policy is used by default and how to change it. Also, it seems odd that write-back pages would be coherent whilst write-through pages aren't - is this a typo? The man page is also inconsistent with /sys/ia64/include/atomic.h which states that atomic operations _are_ SMP safe. I've tried looking at the mutex code to see how the iA64 achieves inter-processor synchronisation on top of (supposedly) non- synchronised atomic(9) primitives but can't find anything. I'd appreciate comments from people familiar with non-iA32 architectures. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rescheduling tasks using swi_add()
--- kamal kc [EMAIL PROTECTED] wrote:
Queue a task to a taskqueue. Behind the scenes
that
will invoke a swi_add if
you use the taskqueue_swi queue. However, given
that you want to do some
rather complicated work, you'd be better off
creating a dedicated taskqueue
thread and queueing tasks off to it I think.
thanks for the suggestion on the taskqueue. i tried
it
on my dummy kernel module and got some output but i
am not sure if i followed the correct steps to
use the taskqueue. the only thing i found
was the man pages and the taskqueue.h.
here is the code:
---
struct taskqueue_arguments
{ int a;
int b;
};
void taskqueue_function(void *,int);
typedef void taskqueue_function_t(void *,int);
/* taskqueue function */
void taskqueue_function(void *arguments,int int_arg)
{
struct taskqueue_arguments *arg;
arg=(struct taskqueue_arguments *)arguments;
printf(\ntakqueue_function was called the args
are %d %d,arg-a,arg-b);
return;
}
/* function implementing the syscall */
static int
hello(struct thread *td, void *arg)
{.
struct task mytask;
taskqueue_function_t *taskqueue_function_ptr;
taskqueue_function_ptr=taskqueue_function;
struct taskqueue_arguments arg_var;
arg_var.a=10;
arg_var.b=20;
TASK_INIT(mytask,50,taskqueue_function_ptr,arg_var);
taskqueue_enqueue(taskqueue_swi, mytask);
...
}
dear all ,
i run the above code and the kernel
would crash whenever i would do the syscall for few
number of times. the crashing process is
(swi6: task queue). the kernel crashes very soon
when i make the system call in a loop.
i guess i didn't follow all the steps to use
the taskqueue
i think some of you can help what did i
miss
thanks,
kamal
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
increasing dd disk to disk transfer rate
My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still working , the errors in the Windows partition are causing Windows do ask for a filesystem check nearly everytime I reboot the computer. One time the error was in the hibernate.sys file, which impedes powering up quickly after a hibernate. Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. In case the the result being unusable I would like to find a way to make this copying faster. Any disk expert here? My motherboard is an ASUS P4S8X with an on board promise controller (currently not in use). System disk is on IDE1 and the two 80GB disks are master/slave on IDE2 bus. I wonder wether I could get better results (transfer rate) when attaching the disks to copy to the promise IDE bus. And another question: Is there a way to tweak the driver (be it the FreeBSD promise driver or the normal ata driver) to use more retries on errors so that I have the chance to copy everything or nearly everything of the already degrading hard disk? -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
On Thu, Jan 12, 2006 at 10:48:38AM +0100 I heard the voice of Christoph Kukulies, and lo! it spake thus: dd if=/dev/ad2 of=/dev/ad3 conv=noerror Give it a bigger blocksize (say, bs=1m or so) and it'll go a **LOT** faster. My motherboard is an ASUS P4S8X with an on board promise controller (currently not in use). System disk is on IDE1 and the two 80GB disks are master/slave on IDE2 bus. You'll get much better results by having each drive be master on its own bus. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
Christoph Kukulies wrote: My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still working , the errors in the Windows partition are causing Windows do ask for a filesystem check nearly everytime I reboot the computer. One time the error was in the hibernate.sys file, which impedes powering up quickly after a hibernate. Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror Specify a larger block size - the default is 512bytes, which is not efficient for what you are doing. Maybe 1mb would be the right number. The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. In case the the result being unusable I would like to find a way to make this copying faster. Any disk expert here? My motherboard is an ASUS P4S8X with an on board promise controller (currently not in use). System disk is on IDE1 and the two 80GB disks are master/slave on IDE2 bus. Also, put the disks on separate IDE busses - one disk on ide1, the other on ide2. This will help a lot.. I wonder wether I could get better results (transfer rate) when attaching the disks to copy to the promise IDE bus. And another question: Is there a way to tweak the driver (be it the FreeBSD promise driver or the normal ata driver) to use more retries on errors so that I have the chance to copy everything or nearly everything of the already degrading hard disk? Not sure about that.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
Christoph Kukulies wrote: Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. The default block size for dd is 512 bytes, meaning dd will read 512 bytes from one disk and write them to the other before reading again. This is SLOW. You need to specify a larger block size to use it effectively, like adding bs=1m argument to dd (which will make it use 1 MB blocks). Also, you should probably add sync to your conv argument, see the manual page of dd. I don't know if using sync will produce a full 1 MB of zeros when a bad sector is encountered - I hope someone else will clarify this :) Btw. I don't think this is the right group for your question - in the future use [EMAIL PROTECTED] or [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: increasing dd disk to disk transfer rate
My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to
develop read errors.
Since you are using a modern disk, you should check your smart counters. I
know how to do it on NetBSD, and I believe the command is also available on
FreeBSD. First, you have to turn on the smart (S.M.A.R.T.) stuff on the
hard-disk.
Then you can poll the hard disk and have counters reported back to you with
precious information about errors :)
Here is what I get from atactl on NetBSD :
{/root}
[root][1] atactl wd0 smart status
SMART supported, SMART enabled
id value thresh crit collect reliability descriptionraw
1 100 51 yes online positiveRaw read error rate0
3 100 25 yes online positiveSpin-up time 2944
4 1000 no online positiveStart/stop count 453
5 253 10 yes online positiveReallocated sector count 0
7 2530 no online positiveSeek error rate0
8 2530 no offline positiveSeek time performance 0
9 1000 no online positivePower-on hours count 7010
10 2530 no online positiveSpin retry count 0
12 1000 no online positiveDevice power cycle count 9
191 1000 no online positiveGsense error rate 35
194 1120 no online positiveTemperature42
195 1000 no online positiveHardware ECC Recovered
1981492
196 2530 no online positiveReallocated event count0
197 2530 no online positiveCurrent pending sector 0
198 2530 no offline positiveOffline uncorrectable 0
199 2000 no online positiveUltra DMA CRC error count 0
200 1000 no online positiveWrite error rate 0
201 2530 no online positiveSoft read error rate 0
223 2530 no online positiveLoad/unload retry count0
225 1000 no online positiveLoad/unload cycle count5513
255 1000 no online positiveUnknown0
So by checking your own counters, you might get hints from the hardware that
something is wrong there.
Then, there is a web page with tools from Hitachi (IBM) that allow you to
boot and check your disk :
http://www.hitachigst.com/hdd/support/download.htm
Which such tools, you can have access to some functions that are not
available from our beloved BSD like turning ON the check the noise you do
and try to be quiet option :)
The feature tool will let you do that :
Change the drive Automatic Acoustic Management settings to the:
* Lowest acoustic emanation setting (Quiet Seek Mode), or
* Maximum performance level (Normal Seek Mode).
I was using a disk like yours on my Thinkpad X30. I replaced it with a
Samsung which has the same kind of tools available and usually in the form
of bootable floppies.
Hope this will help !
--
unzip ; strip ; touch ; grep ; find ; finger ; mount ; fsck ; more ; yes ;
fsck ; umount ; sleep
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
In the last episode (Jan 12), Christoph Kukulies said: My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still working , the errors in the Windows partition are causing Windows do ask for a filesystem check nearly everytime I reboot the computer. One time the error was in the hibernate.sys file, which impedes powering up quickly after a hibernate. Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. Everybody has mentioned the first obvious fix: raise your blocksize from the default 512 bytes. The second fix addresses the problem that with a single dd, you are either reading or writing. If you pipe the first dd into a second one, it'll let you run at the max speed of the slowest device. dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k -- 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: increasing dd disk to disk transfer rate
In the last episode (Jan 12), Christoph Kukulies said: My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still working , the errors in the Windows partition are causing Windows do ask for a filesystem check nearly everytime I reboot the computer. One time the error was in the hibernate.sys file, which impedes powering up quickly after a hibernate. Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. Everybody has mentioned the first obvious fix: raise your blocksize from the default 512 bytes. The second fix addresses the problem that with a single dd, you are either reading or writing. If you pipe the first dd into a second one, it'll let you run at the max speed of the slowest device. dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do a better job of recovering. Assuming he has backups. Windows is pickier about things but I am sure there are windows tools that will handle all that and allow more retries. dd is the *wrong* tool for what he wants to do. If it were upto me first I'd backup all the data I may need; using multiple retries and all that and then install freebsd from scratch on the new *bigger* disk. Perfect time for house cleaning and removing all those ports you don't use any more! As for windows I'd use the recovery disk and in effect reinstall windows from scrach and then reinstall all apps and move over my data files. [What I actually do is to run win2k under qemu on my laptop. Good enough for what I need it for] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
Bakul Shah wrote: In the last episode (Jan 12), Christoph Kukulies said: dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do The problem is, FreeBSD panics when it encounters bad sectors in filesystem metadata. I had the same situation ~a month ago and gave up, restoring from old backups. It will also probably panic on corrupted or zeroed metadata, but at least it's on a readable disk... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ricoh PCI to SD device?
On Thu, Jan 12, 2006 at 12:00:31PM +, [EMAIL PROTECTED] wrote: Date: Wed, 11 Jan 2006 10:32:16 -0800 From: Darren Pilgrim [EMAIL PROTECTED] Subject: RE: Ricoh PCI to SD device? To: 'M. Warner Losh' [EMAIL PROTECTED] Cc: freebsd-hackers@freebsd.org From: M. Warner Losh [mailto:[EMAIL PROTECTED] ... Are you sure they provide technical documentation sufficent to write the driver? The last time I asked, I got a nice document that said that it implemented the sds standard sd host interface, but didn't document what that was. TI and winbond chips datasheets are the same way. Prove me wrong. I'd love it :-) The SD protocols aren't open standards. Ricoh can't legally include information about the protocols in their documentation. Without working implementation of the SDA's standards, FreeBSD is stuck. I don't blame the funding behind FreeBSD development for not ponying up the dosh; I think such fees are extortion made legal by intellectual property laws. But hey, it's the business. It's not like we're trying to make a good, free product everyone can use, right? IANAL, but it sounds like there are more serious issues than the money. If that NDA says some fairly typical things, and if the FreeBSD organization (or any individual developer) poneys up the money for the standard and signs the associated NDA, then either that developer or the FreeBSD group as a whole might then be permanently barred from writing open source code to implement the protocol, as a working implementation could disclose protocol information covered as a secret by the NDA. I'm sure that's *not* what you want to see. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
Bakul Shah wrote: In the last episode (Jan 12), Christoph Kukulies said: dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do The problem is, FreeBSD panics when it encounters bad sectors in filesystem metadata. I had the same situation ~a month ago and gave up, restoring from old backups. It will also probably panic on corrupted or zeroed metadata, but at least it's on a readable disk... Good point. Would fsdb help? If not someone ought to extend it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
Bakul Shah wrote: Bakul Shah wrote: In the last episode (Jan 12), Christoph Kukulies said: dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do The problem is, FreeBSD panics when it encounters bad sectors in filesystem metadata. I had the same situation ~a month ago and gave up, restoring from old backups. It will also probably panic on corrupted or zeroed metadata, but at least it's on a readable disk... Good point. Would fsdb help? If not someone ought to extend it. I think after the dd is done, fsck should be run against the affected filesystems, which should take care of most of the issues. The OP's question was how to make dd faster, not really how to get the data across safely. :) Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
I think after the dd is done, fsck should be run against the affected filesystems, which should take care of most of the issues. For metadata yes, but not for normal file data. He wouldn't even know what got trashed. The OP's question was how to make dd faster, not really how to get the data across safely. :) Sometime you have to answer the question they should've asked! That is what a diagnostician has to do. Fix the cause. Not the symptom. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atomic operations across multiple processors
On Thursday 12 January 2006 03:52 am, Peter Jeremy wrote:
atomic(9) states:
The current set of atomic operations do not necessarily guarantee atomic-
ity across multiple processors. ... On the i386 architecture, the cache
coherency model requires that the hardware perform this task, thus the
atomic operations are atomic across multiple processors. On the ia64
architecture, coherency is only guaranteed for pages that are configured
to using a caching policy of either uncached or write back.
Unfortunately, this doesn't document the behaviour for other
architectures - this makes it difficult to write portable code.
For the ia64, the statement isn't especially helpful because there's
no indication of what caching policy is used by default and how to
change it. Also, it seems odd that write-back pages would be coherent
whilst write-through pages aren't - is this a typo? The man page is
also inconsistent with /sys/ia64/include/atomic.h which states that
atomic operations _are_ SMP safe.
I've tried looking at the mutex code to see how the iA64 achieves
inter-processor synchronisation on top of (supposedly) non-
synchronised atomic(9) primitives but can't find anything.
I'd appreciate comments from people familiar with non-iA32 architectures.
What it is trying to communicate is the fact that the results of an atomic
operation are not immediately visible on other CPUs. That is, other CPUs may
have stale values in cache, etc. On i386 the caching policy doesn't really
allow that much as lines get evicted when other CPUs write to them. On
sparc9 for example, writes can sit in a store buffer for a while before they
are posted to main memory, and other CPUs in the system won't see the effect
of the write until then. However, if another CPU tries to do a cas on the
same variable, it will either block or fail (not sure which, might be
implementation dependent). That's all the mutex code needs though. Here's
the non-hairy parts of _mtx_lock_sleep() to show how they work:
while (!_obtain_lock(m, tid)) {
turnstile_lock(m-mtx_object);
v = m-mtx_lock;
/*
* Check if the lock has been released while spinning for
* the turnstile chain lock.
*/
if (v == MTX_UNOWNED) {
turnstile_release(m-mtx_object);
cpu_spinwait();
continue;
}
/*
* If the mutex isn't already contested and a failure occurs
* setting the contested bit, the mutex was either released
* or the state of the MTX_RECURSED bit changed.
*/
if ((v MTX_CONTESTED) == 0
!atomic_cmpset_ptr(m-mtx_lock, v, v | MTX_CONTESTED)) {
turnstile_release(m-mtx_object);
cpu_spinwait();
continue;
}
/*
* Block on the turnstile.
*/
turnstile_wait(m-mtx_object, mtx_owner(m));
}
1) First we try to obtain the lock vi atomic_cmpset_acq(). If it succeeds,
all is happy and we return.
2) If it fails we acquire the turnstile spin lock (really, it's one of several
turnstile locks based on a hash of the lock's KVA). It's important to note
that all manipulation of the MTX_CONTESTED bit happens while this spin lock
is held.
3) We read the value of mtx_lock after acquiring the turnstile lock.
4) We check to see if the lock is now free after we acquired the turnstile
lock. If so, we drop the turnstile lock and try again from the top.
5) If MTX_CONTESTED is set, then we know that the owning thread is going to
fail its simple mutex unlock and will end up in the _mtx_unlock_sleep()
function where it will wake us up, so we go ahead and add ourselves to the
thread queue on the turnstile via turnstile_wait() which will block us and
handle any races in the queue mechanics itself.
6) If MTX_CONTESTED is clear, we need to make sure it is set before we block
to ensure that the owning thread will wake us up when it drops the lock. If
we can't set MTX_CONTESTED, then that means that the value of mtx_lock
doesn't match what we think it is (v), so we drop the turnstile lock and try
again.
That's the simple overview anyway. Now suppose that an arch will fail
atomic_cmpset_ptr() even if mtx_lock == v, but it knows that some other CPU
has a pending write to mtx_lock that it can't see the value of yet (think of
linked-load conditional-store as on Alpha, and available (but not currently
used) on ia64), in that case, it doesn't hurt to just fail
atomic_cmpset_ptr() as we will just spin until other CPUs writes post. So,
in the mutex code, I don't really care if atomic_cmpset_ptr() has failed
because v was stale and the CPU could tell because the actual
Re: rescheduling tasks using swi_add()
On Thursday 12 January 2006 06:19 am, kamal kc wrote:
--- kamal kc [EMAIL PROTECTED] wrote:
Queue a task to a taskqueue. Behind the scenes
that
will invoke a swi_add if
you use the taskqueue_swi queue. However, given
that you want to do some
rather complicated work, you'd be better off
creating a dedicated taskqueue
thread and queueing tasks off to it I think.
thanks for the suggestion on the taskqueue. i tried
it
on my dummy kernel module and got some output but i
am not sure if i followed the correct steps to
use the taskqueue. the only thing i found
was the man pages and the taskqueue.h.
here is the code:
---
struct taskqueue_arguments
{ int a;
int b;
};
void taskqueue_function(void *,int);
typedef void taskqueue_function_t(void *,int);
/* taskqueue function */
void taskqueue_function(void *arguments,int int_arg)
{
struct taskqueue_arguments *arg;
arg=(struct taskqueue_arguments *)arguments;
printf(\ntakqueue_function was called the args
are %d %d,arg-a,arg-b);
return;
}
/* function implementing the syscall */
static int
hello(struct thread *td, void *arg)
{.
struct task mytask;
taskqueue_function_t *taskqueue_function_ptr;
taskqueue_function_ptr=taskqueue_function;
struct taskqueue_arguments arg_var;
arg_var.a=10;
arg_var.b=20;
TASK_INIT(mytask,50,taskqueue_function_ptr,arg_var);
taskqueue_enqueue(taskqueue_swi, mytask);
You can just use the name of the function w/o having to have an explicit
function pointer var:
TASK_INIT(mytask, 50, taskqueue_functino, arg_var);
...
}
dear all ,
i run the above code and the kernel
would crash whenever i would do the syscall for few
number of times. the crashing process is
(swi6: task queue). the kernel crashes very soon
when i make the system call in a loop.
i guess i didn't follow all the steps to use
the taskqueue
i think some of you can help what did i
miss
Are you calling TASK_INIT() while your task is still pending? Just init the
task the first time, then call enqueue() to queue it up. You might want to
call TASK_INIT() during the MOD_LOAD() event in your module handler for
example. Be sure to call taskqueue_drain() during MOD_UNLOAD() to make sure
your task has finished all the pending executes before your module is
unloaded as well.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve = http://www.FreeBSD.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
On Thu, 2006-Jan-12 10:48:38 +0100, Christoph Kukulies wrote: dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. In case the the result being unusable I would like to find a way to make this copying faster. Note that whilst increasing the DD blocksize will speed up the transfer, it will also increase the amount of collateral damage when a hard error occurs. If you rummage around the ports or tools tree, you'll find a utility (its name escapes me but I believe it was written by phk) that is designed to do disk-to-disk recovery - it copys data in big slabs until it gets an error and then works around the faulty area block by block. You should also install /usr/ports/sysutils/smartmontools - this handles S.M.A.R.T. Is there a way to tweak the driver (be it the FreeBSD promise driver or the normal ata driver) to use more retries on errors so that I have the chance to copy everything or nearly everything of the already degrading hard disk? A quick look at the ata driver suggests that there are a number of 'retry' and 'retries' variables/fields. I suspect you could increase the number of retries if you wanted to patch the driver. -- Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
Moin moin, wie geht's :-) Christoph Kukulies wrote on Thu, Jan 12, 2006 at 10:48:38AM +0100: My notebooks' hard disk, a Hitachi Travelstar 80 GB starts to develop read errors. I have FreeBSD and Win XP on that disk. Although FreeBSD ist still working , the errors in the Windows partition are causing Windows do ask for a filesystem check nearly everytime I reboot the computer. One time the error was in the hibernate.sys file, which impedes powering up quickly after a hibernate. Anyway, I decided to buy a second identical hard disk and tried to block by block copy the old disk to the new one using dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. /usr/ports/mis/cstream is a dd-like tool which allows you to specify that it buffers up n megabyte of input before writing to the output. You need that because you are on the same bus with both disks. Use the -B and -b options with some high values. Experiment with the -c option. Is there a way to tweak the driver (be it the FreeBSD promise driver or the normal ata driver) to use more retries on errors so that I have the chance to copy everything or nearly everything of the already degrading hard disk? Just retrying the same block probably doesn't do it. You'll be more successful by seeking to move the head around before retrying. Martin -- %%% Martin Cracauer cracauer@cons.org http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
On Fri, Jan 13, 2006 at 08:13:00 +1100, Peter Jeremy wrote: On Thu, 2006-Jan-12 10:48:38 +0100, Christoph Kukulies wrote: dd if=/dev/ad2 of=/dev/ad3 conv=noerror The process is running now since yesterday evening and it is at 53 MB at a transfer rate of about 1.1 MB/s. In case the the result being unusable I would like to find a way to make this copying faster. Note that whilst increasing the DD blocksize will speed up the transfer, it will also increase the amount of collateral damage when a hard error occurs. If you rummage around the ports or tools tree, you'll find a utility (its name escapes me but I believe it was written by phk) that is designed to do disk-to-disk recovery - it copys data in big slabs until it gets an error and then works around the faulty area block by block. It's called 'recoverdisk', and is in src/tools/tools/recoverdisk. I used it to copy a friend's hard drive, and it worked well. (Although the supposedly 'bad' disk didn't turn out to have any bad sectors.) Ken -- Kenneth Merry [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: increasing dd disk to disk transfer rate
Ivan Voras wrote this message on Thu, Jan 12, 2006 at 18:48 +0100: Bakul Shah wrote: In the last episode (Jan 12), Christoph Kukulies said: dd if=/dev/ad2 conv=noerror,sync bs=64k | dd of=/dev/ad3 bs=64k So now on the new disk he has files with random blocks of zeroes and *no* error indication of which files are so trashed. This is asking for trouble. Silent erros are worse. He ought to do a file level copy, not disk level copy on unix. That way he knows *which* files are trashed and can do The problem is, FreeBSD panics when it encounters bad sectors in filesystem metadata. I had the same situation ~a month ago and gave up, restoring from old backups. It will also probably panic on corrupted or zeroed metadata, but at least it's on a readable disk... Recovery can be possible with ffsrecov.py: http://people.freebsd.org/~jmg/ffsrecov/ -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: increasing dd disk to disk transfer rate
* Peter Jeremy [EMAIL PROTECTED] [2006-01-13 08:13 +1100]: Note that whilst increasing the DD blocksize will speed up the transfer, it will also increase the amount of collateral damage when a hard error occurs. If you rummage around the ports or tools tree, you'll find a utility (its name escapes me but I believe it was written by phk) that is designed to do disk-to-disk recovery - it copys data in big slabs until it gets an error and then works around the faulty area block by block. sysutils/dd_rescue I haven't tried it, but pkg-descr sounds promising. Nicolas -- http://www.rachinsky.de/nicolas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Ricoh PCI to SD device?
From: Clifton Royston If that NDA says some fairly typical things, and if the FreeBSD organization (or any individual developer) poneys up the money for the standard and signs the associated NDA, then either that developer or the FreeBSD group as a whole might then be permanently barred from writing open source code to implement the protocol, as a working implementation could disclose protocol information covered as a secret by the NDA. I'm sure that's *not* what you want to see. In a roundabout way, that's exactly what I'm saying. The SDA, by their actions, doesn't give a rats posterior about freedom. They're falsely convinced technology standards are a revenue vector and are surviving solely upon Apple, Microsoft, Dell, HP, Sony, Samsung and all the other huge companies having the capital to just pony up their extortionist fees rather than making a moral stand. The only reason I have any SD hardware at all is because it was a non-removable option in the notebook I bought. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How priority propagation works on read/write lock?
Hi hackers, I have a question about how priority propagation works on read/write lock.On locks that have only one owner at a determinate moment,we can simply propagate the priority to the owner of lock,but read/write lock may have many owners at some time,so how can we know who are the owners? I browse the OpenSolaris' read/write lock implementation,and find that, it simply treats the owner of the lock as NULL when readers own the read/write lock.In this way,we can not propagate our priority to all threads that block us. Thanks very much. -- Three passions, simple but overwhelmingly strong, have governed my life: the longing for love, the search for knowledge, and unbearable pity for the suffering of mankind. -Bertrand Russell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rescheduling tasks using swi_add()
--- John Baldwin [EMAIL PROTECTED] wrote:
On Thursday 12 January 2006 06:19 am, kamal kc
wrote:
--- kamal kc [EMAIL PROTECTED] wrote:
Queue a task to a taskqueue. Behind the
scenes
that
will invoke a swi_add if
you use the taskqueue_swi queue. However,
given
that you want to do some
rather complicated work, you'd be better off
creating a dedicated taskqueue
thread and queueing tasks off to it I think.
thanks for the suggestion on the taskqueue. i
tried
it
on my dummy kernel module and got some output
but i
am not sure if i followed the correct steps to
use the taskqueue. the only thing i found
was the man pages and the taskqueue.h.
here is the code:
---
struct taskqueue_arguments
{ int a;
int b;
};
void taskqueue_function(void *,int);
typedef void taskqueue_function_t(void *,int);
/* taskqueue function */
void taskqueue_function(void *arguments,int
int_arg)
{
struct taskqueue_arguments *arg;
arg=(struct taskqueue_arguments *)arguments;
printf(\ntakqueue_function was called the
args
are %d %d,arg-a,arg-b);
return;
}
/* function implementing the syscall */
static int
hello(struct thread *td, void *arg)
{.
struct task mytask;
taskqueue_function_t
*taskqueue_function_ptr;
taskqueue_function_ptr=taskqueue_function;
struct taskqueue_arguments arg_var;
arg_var.a=10;
arg_var.b=20;
TASK_INIT(mytask,50,taskqueue_function_ptr,arg_var);
taskqueue_enqueue(taskqueue_swi, mytask);
You can just use the name of the function w/o having
to have an explicit
function pointer var:
TASK_INIT(mytask, 50, taskqueue_functino,
arg_var);
...
}
dear all ,
i run the above code and the kernel
would crash whenever i would do the syscall for
few
number of times. the crashing process is
(swi6: task queue). the kernel crashes very soon
when i make the system call in a loop.
i guess i didn't follow all the steps to use
the taskqueue
i think some of you can help what did i
miss
the problem is solved i guess.
now i used the structure :
struct taskqueue_struct
{ struct task mytask;
int a;
int b;
}
everytime i call TASK_INIT() i allocate memory for
the taskqueue_struct.
and in the handler function deallocate the struct
taskqueue_struct.
this allowed me to do memory safe operation i guess
!!
Are you calling TASK_INIT() while your task is still
pending? Just init the
task the first time, then call enqueue() to queue it
up. You might want to
call TASK_INIT() during the MOD_LOAD() event in your
module handler for
example. Be sure to call taskqueue_drain() during
MOD_UNLOAD() to make sure
your task has finished all the pending executes
before your module is
unloaded as well.
yes , i will do these things. now i will try to make a
separate
taskqueue thread for the job like you said before. i
am
looking at the kthread and other stuffs. i am more
optimistic
now than ever..
i am enjoying these stuffs ..
thanks,
kamal
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
