Re: 3x read to write ratio on dump/restore
Hi Warner, On Friday 09 January 2009 17:50:27 M. Warner Losh wrote: I just copied a disk using dump + restore. I noticed something through the whole run of this 500GB operation: L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 3231231 147549.5 0 00.0 97.5| da1s1a 0 39 0 00.0 39 4982 10.0 38.7| da2s1a The read kBps was 3x the write kBps. While the dump is going through the raw device, and the restore is going through the file system, I can't imagine why we'd have such a huge difference that would be utter consistent for the whole 15 hour run. Any ideas what gives? I observed this with 16MB cache and with 32MB cache, fwiw. I've noticed this too. Last week I upgraded a laptop harddisk and used dump + restore to copy files from the original harddisk (attached to the laptop using a USB bracket). During the entire copy process I also saw about a 3x difference. -- Daan ___ 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
mksnap_ffs time
Hi Hackers, I'm running a 6.2-RELEASE server with a /home partition that's used to backup a customer's data. The backups are being made during the night. Since a couple of weeks I'm running mksnap_ffs daily to create filesystem snapshots of the data. I've been logging the time it takes mksnap_ffs to create it's snapshot. Here are the 'time' numbers for the last 11 days : 1696.25 real 0.00 user16.55 sys 1884.09 real 0.00 user18.63 sys 2038.50 real 0.00 user20.72 sys 2354.69 real 0.00 user25.07 sys 2202.43 real 0.00 user23.08 sys 2621.88 real 0.00 user27.46 sys 2791.46 real 0.00 user29.57 sys 2845.48 real 0.00 user31.69 sys 2894.24 real 0.00 user32.60 sys 3085.37 real 0.00 user35.62 sys 3253.11 real 0.00 user37.25 sys Right now the filesystem contains 'just' 16 snapshots. The filesystem itself is a 700GB partition : # df Filesystem1K-blocks Used Avail Capacity Mounted on ... /dev/twed0s3d 700905640 271350848 37348234242%/home The filesystem has been created with default newfs flags. Today the filesystem contains 186615 files. Average file size is about 140 to 150KB. The data consists of lots of very small files, lots of middle-sized files, and a bunch of huge files, so 'average' file size might not be a very good measure. Every day between 300 to 400MB of data is changed/added. The time it takes to take another snapshot seems to increase with about 140 seconds a day. If the snapshot time keeps increasing in this fashion, the server will spend half of it's time in a day creating snapshots by the end of the year ;-) 1) Is anyone else seeing this? 2) Is there anything that can be done to improve snapshot creation time? 3) Is this something that has already been improved in version X of FreeBSD? And just for my own curiosity: Where does mksnap_ffs spend most of it's time? Is this something that simply can't be changed by the nature of UFS, or is it a known deficiency in the code that could by improved somehow? (btw: I can provide more information on the hardware or the filesystem (file size histograms anyone?) if anyone is interested.) Thanks for any insights, -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mksnap_ffs time
On Friday 04 January 2008 00:30:20 you wrote: Hi! 1) Is anyone else seeing this? As far as I know, this is somehow related to the SoftUpdates, but I am not 100% sure. Look at the mailinglist archives, there was a discussion a few months ago about the same topic as far as I remember. Please note that according to http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/snapshots.html a filesystem can only have 20 snapshots! :-) Hmm.. Then at least time spent per snapshot isn't going to get much worse than it is today ;-) Too bad this limitation isn't mentioned in 'man 8 mksnap_ffs'. If this limitation is still there, I think it deserves a place in the manual. Thanks! -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hooking a kernelmodule-function into a timer interrupt
Hi Michiel,
On Tuesday 20 November 2007 00:51:45 Michiel Overtoom wrote:
I'm interfacing an analog-digital converter to the parallel port and I'm
able to make it work from userland using the ppio driver. But now I want
to move the conversion software into a loadable kernel module, and have the
conversion routine called many times per second, for example 1000 times per
second. If would be nice if it gets called at the kern.clockrate. I have
no clear idea how to proceed, I suspect I have to install a pointer to my
conversion function into some list of functions which get called each clock
tick, but I don't know where, or how. Any tips would be very welcome.
Some more background info: the chip is a ADC08031, hooked up directly to
some input and output pins on the parallel port. The ADC has a serial
output, and I use one pin on the parport to clock it. I want to have the
clocking code executed in some low level timer interrupt handler. I
inserted some test code into 'hardclock()' in 'kern_clock.c' to toggle a
bit on the parport, which worked nicely: it got called 1000 times per
second, which I could actually verify with a frequency meter hooked up to
the parport; but stuffing the conversion software directly into
kern_clock.c would not be an elegant solution.
Next you're going to tell us you desperately need the FPU in your control
loop ;-)
I have done exactly the same as you propose some time ago, but I'm using a
(Humusoft) PCI board with ADCs/DACs. To be able to load control loops from a
kernel module I've done the following :
In kern/kern_clock.c I've added :
typedef void (*control_loop_t)(void *arg);
static void *control_arg;
static control_loop_t control_loop = NULL;
And later on inside hardclock() I've added :
if (control_loop != NULL) {
control_loop(control_arg);
}
This gives you a variable control_loop and control_arg that you can fill
in from your kernel module. control_arg is an optional argument that gets
passed to the function. I use it to transfer a pointer to my driver's softc
structure to the control loop.
In the kernel module you define :
typedef void (*control_loop_t)(void *arg);
extern void *control_arg;
extern control_loop_t control_loop;
Then in your attach or module load function your attach your control
function :
control_arg = sc;
control_loop = loop_func;
Make sure you fill in the argument first as your function could be called the
very instruction after you fill in the function pointer.
On detach or module unload you simply disable your control loop with :
control_loop = NULL;
My control function looks like this :
void loop_func(void *arg)
{
struct softc*card = (struct softc *)arg;
// do something usefull
}
ps: Suc6 met software schrijven ;-)
--
Daan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Floating point in interrupt handler
Hi Warner,
On Wednesday 24 October 2007 23:15:13 you wrote:
In message: [EMAIL PROTECTED]
Daan Vreeken [PA4DAN] [EMAIL PROTECTED] writes:
: But what I haven't found is a description of exactly what the kernel is
: missing to allow floating point operations to be done there.
FPU context is assumed to only change in user processes. You'd have
to fix the FPU state saving code to cope with it changing everywhere,
or you'd have to explicitly put the goo to save/restore it around the
FP you want to do in the kernel.
Issei Suzuki pointed me into the right direction in his reply. (The following
text is an exact copy of the reply I sent to Issei, but I'll just copy it
here to show the code)
If I understand the npx code correctly, there are 2 options when the kernel
arrives at hardclock() :
o The current process is using the FPU (fpcurthread != NULL)
o The current process hasn't used the FPU (yet) since it has been switched to
(fpcurthread == NULL)
In the first case, FPU instructions can be used and will not result in a trap,
but we should save/restore the FPU state before using them so userland
doesn't get confused. In the last case FPU instructions result in a trap, so
we need stop/start_emulating(), but as no one is using the FPU, there is no
need to save/restore it's state.
With this in mind I've come up with the following code :
At the start of the function :
// check FPU state on entry
if (PCPU_GET(fpcurthread) != NULL) {
// someone is using the FPU
// save it's state and remember to put it back later
restore = 1;
fpusave(fpu_state);
} else {
// no one is using the FPU
// enable use of FPU instructions, no need to save it's state
restore = 0;
stop_emulating();
}
// init FPU state every time we get here, as we don't know who has
// been playing with it in between calls
fninit();
control = __INITIAL_NPXCW__;
fldcw(control);
Then we do some floating point arithmetic.
And at the end of the function :
// restore FPU state before we leave
if (restore) {
// restore FPU registers to what they were
fpurstor(fpu_state);
} else {
// no one was using the FPU, so re-enable the FPU trap
start_emulating();
}
With this code trap-22 has stopped to trigger within my function. The FPU
instructions still seem to be executed correctly in my function and when
adding a couple of printf()'s I can see it fpusave() and fpurstor() when
interrupting a userland process that uses the FPU.
Does this look reasonable to everyone?
You had also make sure that the
floating point exceptions never trap, since trapping inside the kernel
has very limited support. You'll have to fix the problems that this
would cause, or force the FPU into a state where it never traps.
According to 'man feenableexcept'. All exceptions are masked by default.
Sure, maybe you can make it happen. However, you are in for much pain
and suffering. The kernel isn't a general purpose computing
environment, and trying to pretend it is will lead to suffering.
Especially inside of an interrupt handler. It is less bad if this is
an ithread, but could be quite painful if you want to do this inside
of a fast interrupt handler to reduce latency.
I'd recommend strongly against trying this and revaluate your true
need for FP in the kernel. From your other mail, you don't seem open
to this answer. If you don't take it, you are setting yourself up for
a lot of pain and suffering. It is your choice, however.
I'm building a system much like Matlab xPC :
http://www.techsource.com.sg/pdts/pdt_details.asp?pcid=2pscid=19
This system will be used by multiple people for various different control
systems. All of them know how to write basic C code, but none of them has
enough programming knowledge to write decent integer math. I'm not a big fan
of using floating point operations inside of the kernel, but if I can't offer
this, I'll have to write all of their control loop routines myself. (And I
really don't have time for that.)
The machines this will run on are dedicated to the control system. I can live
with the machines spending 99% of their CPU time in kernel mode. Userland
will only be used as a nice way to interface with the control loop and to
transfer data and logs in/out.
Userland will almost never use FP instructions. In the test I've done so far
with the above code, FPU save/restore only has to be at most a couple of
times a second.
If you do manage to pull it of, I'd be very interested in see what things I
didn't know to warn you about...
Feel free to punch holes in the code I've written. I'm still rather new to the
FPU internals, so it's highly possible that I've overseen something. So far
testing shows
Re: Floating point in interrupt handler
Hi SorAlx On Tuesday 23 October 2007 03:35:09 you wrote: As a first test I've created a simple loop that uses integer arithmetic and a lookup table to create a sine wave on one of the DAC outputs. This works like a charm, but I really would like to be able to use floating point instructions to create more advanced control loops. So I've added asm inline functions to use the FPU's fsin and fcos operands. At the start of my loop function I (try to) save the FPU state with the following code : why do you need floating point? Your ADCs and DACs are probably no more than 16 bit anyway. Because of several reasons. The most important one being that it's a work related project. I'm the one developing the driver, not the one that's going to write the control loop. I need this driver to be usable by anyone with basic mathematical/programming skills. The second reason would be : because I know it can be done. The code I currently have successfully uses floating point instructions in the kernel. Any modern CPU can execute extreme amounts of floating point instructions per second. Please lets not try to discuss the (dis)advantages of integer math vs. floating point. I know how to write integer math, but it's not what I'm looking for for this project. Thanks, -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Floating point in interrupt handler
On Tuesday 23 October 2007 07:52:41 Issei Suzuki wrote:
2007/10/23, Daan Vreeken [PA4DAN] [EMAIL PROTECTED]:
So I've added asm inline functions to use the FPU's fsin and fcos
operands. At the start of my loop function I (try to) save the FPU state
with the following code :
td = curthread;
npxgetregs(td, fpu_state);
At the end of the function I restore the FPU state with :
npxsetregs(td, fpu_state);
In between I currently have :
// create a 500Hz sine wave, modulate it with a 2Hz sine wave and
// let it have a 10.0 Volt amplitude
t += 0.0001;
set_dac_voltage(card, 0,
fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0);
As uggly as the code may seem, it works and the output of the acquisition
board shows the expected signal on a scope. While the code seems to do
what it should, the kernel floods the console with the following message
: kernel trap 22 with interrupts disabled
In FreeBSD, FPU context switch is delayed until FPU is used for the
first time after user thread is switched. To achieve this, T_DNA
(FPU device not available trap) is used as follows.
(Before switching thread)
1. Save FPU state and enable DNA trap (npxsave() @ /sys/i386/isa/npx.c).
After this, DNA trap occurs when you access FPU.
(Switch to another user thread)
2. User thread accesses FPU.
3. T_DNA trap occurs, and npxdna() @ /sys/i386/isa/npx.c is called.
4. Initialize FPU state (1st time) or restore FPU state (2nd times or
later). 5. Return to user mode, and user thread access FPU again.
So, to use FPU in kernel, you must clear T_DNA trap and initialize FPU
registers first.
Reading these functions may help you, I think.
/sys/i386/isa/npx.c
start_emulating()
stop_emulating()
npxdna()
Thanks for the insights, this has helped a lot. If I understand the code
correctly, there are 2 options when the kernel arrives at hardclock() :
o The current process is using the FPU (fpcurthread != NULL)
o The current process hasn't used the FPU (yet) since it has been switched to
(fpcurthread == NULL)
In the first case, FPU instructions can be used and will not result in a trap,
but we should save/restore the FPU state before using them so userland
doesn't get confused. In the last case FPU instructions result in a trap, so
we need stop/start_emulating(), but as no one is using the FPU, there is no
need to save/restore it's state.
With this in mind I've come up with the following code :
At the start of the function :
// check FPU state on entry
if (PCPU_GET(fpcurthread) != NULL) {
// someone is using the FPU
// save it's state and remember to put it back later
restore = 1;
fpusave(fpu_state);
} else {
// no one is using the FPU
// enable use of FPU instructions, no need to save it's state
restore = 0;
stop_emulating();
}
// init FPU state every time we get here, as we don't know who has
// been playing with it in between calls
fninit();
control = __INITIAL_NPXCW__;
fldcw(control);
Then we do some floating point arithmetic.
And at the end of the function :
// restore FPU state before we leave
if (restore) {
// restore FPU registers to what they were
fpurstor(fpu_state);
} else {
// no one was using the FPU, so re-enable the FPU trap
start_emulating();
}
With this code trap-22 has stopped to trigger within my function. The FPU
instructions still seem to be executed correctly in my function and when
adding a couple of printf()'s I can see it fpusave() and fpurstor() when
interrupting a userland process that uses the FPU.
Does this look reasonable to everyone?
Thanks,
--
Daan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Floating point in interrupt handler
Hi all, For a work related project I'm trying to create a sort of real-time control loop. I've written a driver for a PCI data acquisition card that features a number of digital-to-analog and analog-to-digital converters. The goal is to create a control loop that runs about 1 times a second and can be altered on the fly. The control loop should always run, running the rest of FreeBSD (kernel and userland) is less important. To achieve this I've been playing with some modifications to hardclock(). I have added hooks to hardclock() that will call my external loop function once attached. The loop function lives in a seperate kernel module that can be loaded and unloaded on the fly. After changing HZ to 1 I now have a function that gets called 1 times a second that can manipulate the outputs of the acquisition board. As a first test I've created a simple loop that uses integer arithmetic and a lookup table to create a sine wave on one of the DAC outputs. This works like a charm, but I really would like to be able to use floating point instructions to create more advanced control loops. So I've added asm inline functions to use the FPU's fsin and fcos operands. At the start of my loop function I (try to) save the FPU state with the following code : td = curthread; npxgetregs(td, fpu_state); At the end of the function I restore the FPU state with : npxsetregs(td, fpu_state); In between I currently have : // create a 500Hz sine wave, modulate it with a 2Hz sine wave and // let it have a 10.0 Volt amplitude t += 0.0001; set_dac_voltage(card, 0, fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); As uggly as the code may seem, it works and the output of the acquisition board shows the expected signal on a scope. While the code seems to do what it should, the kernel floods the console with the following message : kernel trap 22 with interrupts disabled As I'm completely new to saving/restoring the FPU state and working with it from within the kernel (and especially from within an interrupt handler) I'm not sure if all the above is the correct way to do things, so please correct me if I'm doing things wrong. I'm also not sure if the FPU state is correctly restored and I haven't done any tests (yet) to check this, but judging by the amount of trap-22 messages I'm getting, I must be doing something wrong ;-) I have done some Googling and found a couple of interresting threads to read : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-03/msg00096.html http://lists.freebsd.org/pipermail/freebsd-emulation/2007-April/003448.html But what I haven't found is a description of exactly what the kernel is missing to allow floating point operations to be done there. Can anyone tell if I'm saving/restoring the FPU state the right way in the code snippets above and what I should do to correctly stop trap 22 from occuring? Thanks, -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Floating point in interrupt handler
Hi all, For a work related project I'm trying to create a sort of real-time control loop. I've written a driver for a PCI data acquisition card that features a number of digital-to-analog and analog-to-digital converters. The goal is to create a control loop that runs about 1 times a second and can be altered on the fly. The control loop should always run, running the rest of FreeBSD (kernel and userland) is less important. To achieve this I've been playing with some modifications to hardclock(). I have added hooks to hardclock() that will call my external loop function once attached. The loop function lives in a seperate kernel module that can be loaded and unloaded on the fly. After changing HZ to 1 I now have a function that gets called 1 times a second that can manipulate the outputs of the acquisition board. As a first test I've created a simple loop that uses integer arithmetic and a lookup table to create a sine wave on one of the DAC outputs. This works like a charm, but I really would like to be able to use floating point instructions to create more advanced control loops. So I've added asm inline functions to use the FPU's fsin and fcos operands. At the start of my loop function I (try to) save the FPU state with the following code : td = curthread; npxgetregs(td, fpu_state); At the end of the function I restore the FPU state with : npxsetregs(td, fpu_state); In between I currently have : // create a 500Hz sine wave, modulate it with a 2Hz sine wave and // let it have a 10.0 Volt amplitude t += 0.0001; set_dac_voltage(card, 0, fp_sin(500 * 2 * M_PI * t) * fp_sin(2 * 2 * M_PI * t) * 10.0); As uggly as the code may seem, it works and the output of the acquisition board shows the expected signal on a scope. While the code seems to do what it should, the kernel floods the console with the following message : kernel trap 22 with interrupts disabled As I'm completely new to saving/restoring the FPU state and working with it from within the kernel (and especially from within an interrupt handler) I'm not sure if all the above is the correct way to do things, so please correct me if I'm doing things wrong. I'm also not sure if the FPU state is correctly restored and I haven't done any tests (yet) to check this, but judging by the amount of trap-22 messages I'm getting, I must be doing something wrong ;-) I have done some Googling and found a couple of interresting threads to read : http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2007-03/msg00096.html http://lists.freebsd.org/pipermail/freebsd-emulation/2007-April/003448.html But what I haven't found is a description of exactly what the kernel is missing to allow floating point operations to be done there. Can anyone tell if I'm saving/restoring the FPU state the right way in the code snippets above and what I should do to correctly stop trap 22 from occuring? Thanks, -- Daan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic at boot on any 6.x OS
On Sunday 25 February 2007 08:59, Kip Macy wrote:
It looks as if you've hit a device driver that is trying to print out
a null string. The message you've given doesn't provide any more
information than that. If you install a snapshot kernel it will
probably have ddb compiled in which will allow you to at least get a
backtrace. I'm sorry you're having trouble.
Grepping the source tree on 6.2-RELEASE shows this message can only have com
from one place : sys/kern/kern_conf.c in the function prep_cdevsw() :
if (devsw-d_version != D_VERSION_01) {
printf(
WARNING: Device driver \%s\ has wrong version %s\n,
devsw-d_name == NULL ? ??? : devsw-d_name,
and is disabled. Recompile KLD module.);
Looks like the kernel and the modules are out of sync.
On 2/24/07, Joe Auty [EMAIL PROTECTED] wrote:
Hello,
(sorry, don't know whether kernel problems should go to questions or
hackers, or both)..
This has been a long-standing problem of mine, but I always ignored
it hoping it would go away on its own with a future 6.x release, but
it remains...
No matter whether I boot into safe mode or regular mode, with all
kernel extensions disabled in /boot/loader.conf, I get the following
panic late at boot of a fresh RELENG_6_2 kernel (with only a few
services left to bring up). The 6.x kernels I've tried all build and
installed cleanly without any errors...
WARNING: Device driver
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x40
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc06d4614
stack pointer = 0x28:0xf015491c
frame pointer = 0x28:0xf015491c
code segment = base 0x0, limit 0xff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interupt enabled, resume, IOPL = 0
current process = 898 (kldload)
trap number = 12
panic: page fault
uptime: 36s
cannot dump. No dump device defined
automatic reboot in 15 seconds
This problem does not occur within any 5.x OS for me. I would
certainly like to resolve this issue now, but this sort of debugging
is over my head beyond running fsck (which I've tried). Any ideas here?
Thanks in advance for your help!
---
Joe Auty
NetMusician: web publishing software for musicians
http://www.netmusician.org
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
--
Daan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stop further socket() or connect() calls.
On Wednesday 05 July 2006 03:15, mal content wrote:
On 03/07/06, Peter Jeremy [EMAIL PROTECTED] wrote:
For dynamic executables, you could LD_PRELOAD a .so that replaces
all the socket-related syscalls.
Excellent suggestion! Ok, I've created a basic .so file with the following
code, but I've basically got stuck because I don't know how the original
syscalls are defined and can't find the definitions in the source:
---
#include sys/syscall.h
#include sys/types.h
#include sys/socket.h
int socket(int d, int t, int prot)
{
return __syscall(SYS_socket, d, t, prot);
}
[ ... ]
Wouldn't this still allow a program to open sockets when the program does the
__syscall() dance for itself instead of relying on socket() to work?
I have never tried MAC myself, so correct me if I'm wrong, but I think
something like this could be done using a modified version of mac_portacl(4).
grtz,
Daan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using sysarch specific syscalls in assembly?
On Wednesday 10 August 2005 15:09, alexander wrote:
I tried to write a little C app that uses sysarch and i386_set_ioperm to
gain access to certain ports and after a bit of testing I'm pretty sure
that there is a bug or better a timing issue with the sysarch syscall or
the
i386_set_ioperm procedure. Please have a look at the following code:
//CODE START
#include machine/sysarch.h
int main (void) {
unsigned int port = 0x378;
unsigned char val = 'A';
int number = 4;
static inline void outb (unsigned short int port, unsigned char val) {
__asm__ volatile (outb %0,%1\n::a (val), d (port) );
}
struct i386_ioperm_args {
unsigned int start;
unsigned int length;
int enable;
};
struct i386_ioperm_args *args;
struct i386_ioperm_args arg;
args = arg;
args-start = 0x378;
args-length = 1;
args-enable = 1;
if(sysarch(number,args) == 0) {
/* int i;
for(i=0; i 100; i++) {
printf(DELAY\n);
}
*/
outb(0x378,0xF);
exit(0);
}
else {
printf(Error during syscall);
exit(1);
}
}
//eof
//CODE END
On my PC this code will cause a core dump (Bus error: 10). If I however add
a delay (the code that's commented out) the app will end without any
errors.
It seems FBSD needs some time to set the I/O permissions for an app. Can
somebody test this code on his computer? Maybe this is a bug in RELENG_6.
I'm running:
FreeBSD 6.0-BETA1 #0: Mon Jul 18 03:00:45 CEST 2005
I can confirm that. I have tested the program on 5.4-RELEASE here. Testing
your program (I called it p) 10 times gives the following output :
[EMAIL PROTECTED] for a in 0 1 2 3 4 5 6 7 8 9;do echo starting p; ./p ;done
starting p
starting p
starting p
Bus error (core dumped)
starting p
Bus error (core dumped)
starting p
starting p
starting p
Bus error (core dumped)
starting p
Bus error (core dumped)
starting p
starting p
[EMAIL PROTECTED]
However, opening /dev/io to gain IO privileges instead of using sysarch always
works. I tested that with the following program :
#include fcntl.h
static inline void outb (unsigned short int port, unsigned char val) {
__asm__ volatile (outb %0,%1\n::a (val), d (port) );
}
int main (void) {
if (open(/dev/io, O_RDONLY) == -1) {
printf(EEK!\n);
exit(1);
}
outb(0x378, 0xff);
}
--- EOF ---
grtz,
Daan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem (interrupt storm) with snd_ich
Hi All, I'm having a problem with the snd_ich driver. Directly after loading the snd_ich module pcm0 is detected correctly, but vmstat -i shows about 4 interrupts every second caused by pcm0. The problem shows up with both custom kernels and GENERIC, with or without snd_ich compiled into the kernel. After adding a printf() to the ich_intr() routine it showed that all interrupts have 0x400 (ICH_GLOB_STA_PRES) set. The ich_intr() has a comment about clearing this interrupt in the following lines : /* Clear resume interrupt(s) - nothing doing with them */ ich_wr(sc, ICH_REG_GLOB_STA, gs, 4); Although this code should clear the interrupt, this doesn't seem to work on my laptop somehow. In ich_init() ICH_GLOB_CTL_PRES gets set in the ICH_REG_GLOB_CNT register. If I remove this bit in ich_init(), the interrupt problem goes away and pcm0 works as expected. I have changed the following line in ich_init() : Original line : ich_wr(sc, ICH_REG_GLOB_CNT, ICH_GLOB_CTL_COLD | ICH_GLOB_CTL_PRES, 4); New line : ich_wr(sc, ICH_REG_GLOB_CNT, ICH_GLOB_CTL_COLD, 4); I'm not an ICH expert, so I don't know if I have just disabled a suspend/resume feature that is really needed or not, but it does solve my problem. I would like to know if anyone else has seen this problem before, and if there is a better solution to it. The relevant part of pciconf -lv : [EMAIL PROTECTED]:2:7: class=0x040100 card=0x17631043 chip=0x70121039 rev=0xa0 hdr=0x00 vendor = 'Silicon Integrated Systems (SiS)' device = 'SiS7012 PCI Audio Accelerator' class= multimedia subclass = audio Feel free to ask for more information. I'm willing to test patches and give feedback. Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EHCI Kernel Panic w/ 5.2.1-RELEASE Kernel
On Monday 01 November 2004 16:09, Martes Wigglesworth wrote: My kernel panic seems to come from the usb port actually having a device in the port, at boot. When I do not have a device in the port, bootup continues, however, my usb ports are not usable. This is my dmesg output. dmesg|grep usb usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 Over a week ago I discovered a bug in the UHCI driver that causes problems when devices are plugged in during boot. I filed a PR with a patch that has been taken into the UHCI driver in -CURRENT : http://www.freebsd.org/cgi/query-pr.cgi?pr=73000 Can you try the patch that's at the end of the PR on your system? (It should patch without a problem on 5.2.1-RELEASE). I'm not sure if it fixes your problem since your problem seems to be EHCI-related, but you never know. Good luck, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 07:23, Brandon Erhart wrote: Thank you. You are my new god. I had checked out a version of valgrind for BSD (one of the patches) and it failed to compile. Everything seems to be working, except I get this warning at the beginning of the program: Warning: ignoring --pointercheck=yes, because i386_set_ldt failed (errno=45) Sounds like you need options USER_LDT in you kernel. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP.. USB MFC coming..
On Saturday 28 February 2004 02:54, Julian Elischer wrote: I plan to commit the MFC at http://www.josef-k.net/freebsd/ (the latest one) in the next couple of days. If you really care about USB in 4.10 you might do well to test this on your equipment, ESPECIALLY if you have unusual devices. Let me know of both successes and failures please.. If I hear nothing I won't know if it's because no-one tested it or it was just without problems.. If you have any time left on your schedule, maybe you could have a look at 2 pr's I have filed about the USB stack. Both problems can crash a system easilly and both contain a patch to fix it : kern/59290: [PATCH] attaching more than one of the same usb if_* adapters crashes system kern/51186: pointer arithmatic error in ugen.c Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP.. USB MFC coming..
On Saturday 28 February 2004 16:32, you wrote: thankyou.. I haven't looked a the PR yet but does it happen in 5.x and 4.x? Yes, as far as I know both problems are in 4.x and 5.x . On Sat, 28 Feb 2004, Daan Vreeken [PA4DAN] wrote: On Saturday 28 February 2004 02:54, Julian Elischer wrote: I plan to commit the MFC at http://www.josef-k.net/freebsd/ (the latest one) in the next couple of days. If you really care about USB in 4.10 you might do well to test this on your equipment, ESPECIALLY if you have unusual devices. Let me know of both successes and failures please.. If I hear nothing I won't know if it's because no-one tested it or it was just without problems.. If you have any time left on your schedule, maybe you could have a look at 2 pr's I have filed about the USB stack. Both problems can crash a system easilly and both contain a patch to fix it : kern/59290: [PATCH] attaching more than one of the same usb if_* adapters crashes system kern/51186: pointer arithmatic error in ugen.c Thanks, Daan Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Release USB WLAN driver version 0.2 - testers wanted
Hi, Some time ago I released the first public version of my atuwi driver (for Atmel usb wireless adapters). Since then I have made a lot of changes to the code and today it's time to release the next version... Version 0.2 features : * A nice step-by-step guide to installing and using the driver. * Support for both RFMD and Intersil radio parts. * Support for Ad-hoc networks. * Support for Infrastructure mode (currently in infrastructure mode only 'open system' authentication is implemented). * Setting the channel / SSID / WEP mode / WEP key / mac-addr via ifconfig. * Automatic scanning and associating with a wireless network. * BPF support for both DLT_EN10MB and DLT_IEEE802_11. * Improving the speed by issuing multiple transfers at the same time. * Decreasing processing overhead with what I would like to call Lazy transmit net-isr scheduling. If you happen to have a USB WLAN adapter or if you're just interrested in my usb-improvements, feel free have a look at the driver : http://vitsch.net/bsd/atuwi/ I'd be happy to hear any possitive / negative feedback. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1 Installation probelms
On Sunday 11 January 2004 11:29, 70uf33q Hu5541n wrote: hey guys, Just got my copy of FreeBSD 5.1. Spent about an hour going through the BSD Handbook and preparing a Installation checklist. ok here's my problem. I have a WD 40 GB HDD the primary partition is 10 GB, with the extended partition 28 GB.(the rest 2 GB is in WD's bank). OK , the extended partition has 3 logical drives. To create a slice for BSD, I resized one of the logical drives to free up some space. About 1.2 GB,cause that's all I can spare. When I run the installation through CDROM, and the point where I'm to creat the Freebsd slice,the new partition is not displayed in the FDISK utility. All I get is the primary (10GB) and the whole Extended (28 GB). The freespace I guess is locked into the Extended Partiton. Not sure though. Indeed you first have to resize the extended partition before you can use the space to create slices. The fdisk program that comes with Windows has no way to do this (except deleting all logicle drives in the extended partition and re-creating them). Have a look at the program Partition Magic. It can resize partitions and it has a nice user interface. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UNIX / BSD parallel port programming documentation
On Friday 09 January 2004 17:03, Vladimir Terziev wrote: Hi hackers, I have to develop small server which has to manage custom microcontroller via parallel port interface. Does anyone know good manual/documentation about UNIX / BSD parallel port programming ? Most of it should already be on your system, have a look at the man-pages. If you want to use the ppbus interface to control the port : man lpt(4), ppbus(4) and ppi(4) If you want to directly address the ports registers yourself without using the driver interface : man io(4) and have a look at /usr/include/machine/cpufunc.h On FreeBSD you need to have opened /dev/io before your program is allowed to do direct IO to any device, and on Linux you need to successfully call ioperm() first. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel threads and printf locking question
Hi, I am writing a kernel module in which I have created a kernel thread with kthread_create. For debugging I have added a couple of printf's in the thread-routine. Running the module on a single-proc system works fine, but when running it on one of my SMP machines the console freezes after a couple of seconds. I have been looking through the archives and through some other drivers ( for example randomdev.c uses a kthread and printf's from it ). I found a version of randomdev.c with google that lock's Giant while calling printf, but randomdev.c in my src-tree has no locking there. (I'm using 5.1-RELEASE) Right now I have changed all printf's in my module into a macro-function that checks if ( curproc == our thread ) and locks Giant if true, then printf's. (since some of the routines get called both from the thread and from other places.) What is the current state of printf-locking when called from a kernel thread? Is locking Giant the only possible way to avoid problems on SMP systems, or is there a more fine-grained printf lock available? (on 5.1-RELEASE or -current) thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB stack / configuration 0
On Thursday 08 January 2004 07:01, Bernd wrote:
Im mostly worried about having more than a single device with address 0.
You can't do this as long as another device gets initialized.
Therefor I thought disabling/enabling the port would be better, but I'm
wrong as the result is be the same.
With the changes I have made, it is only possible to let the USB stack reset
the device from the ATTACH routine of a driver. This should garantee that
there is only one device with addr==0 , since the probe attach routines are
only called from one process.
For my device driver I have made a small change to the USB Stack and I
have introduced the return code USB_ATTACH_NEED_RESET for drivers to
tell the USB Stack thee device needs to be re-enumerated. The stack then
automatically re-assigns the device it's address, and re-probes for
drivers. This way even two seperate drivers could be made : one with the
firmware and one with the real driver.
Is anyone interrested in a patch maybe?
Sounds interesting.
Have a look at the patch attached to this mail.
My idea is to let a driver upload the firmware from it's ATTACH routine and
after that return with USB_ATTACH_NEED_RESET. Since some devices really
require a reset to be sent to it and others only need to be re-configured,
the USB stack doesn't send the reset itself. The ATTACH function is
responsible for sending the reset to the device.
After getting the NEED_RESET response, the USB stack assumes the device is
ready and listening at addr==0 again. The stack re-reads the device
descriptor, sets the address again and tries another round of attaching
drivers. We give up after 5 rounds of NEED_RESET.
If anyone knows a more elegant way to achieve the same functionality, I'm open
to ideas :)
grtz,
Daandiff -ur usb.org/usb_port.h usb/usb_port.h
--- usb.org/usb_port.h Wed Oct 2 09:44:20 2002
+++ usb/usb_port.h Wed Jan 7 20:26:55 2004
@@ -435,6 +435,7 @@
/* Returns from attach */
#define USB_ATTACH_ERROR_RETURN return ENXIO
#define USB_ATTACH_SUCCESS_RETURN return 0
+#define USB_ATTACH_NEED_RESET return EAGAIN
#define USB_ATTACH_SETUP \
sc-sc_dev = self; \
diff -ur usb.org/usb_subr.c usb/usb_subr.c
--- usb.org/usb_subr.c Wed Jan 15 00:07:43 2003
+++ usb/usb_subr.c Wed Jan 7 22:50:20 2004
@@ -86,6 +86,9 @@
Static int usbd_print(void *aux, const char *pnp);
Static int usbd_submatch(device_ptr_t, void *, void *);
#endif
+Static usbd_status usbd_new_device2(device_ptr_t parent, usbd_bus_handle bus,
+ int depth, int speed, int port,
+ struct usbd_port *up);
Static void usbd_free_iface_data(usbd_device_handle dev, int ifcno);
Static void usbd_kill_pipe(usbd_pipe_handle);
Static usbd_status usbd_probe_and_attach(device_ptr_t parent,
@@ -131,6 +134,7 @@
SHORT_XFER,
STALLED,
INTERRUPTED,
+ NEED_RESET,
XXX,
};
@@ -888,6 +892,14 @@
uaa.ifaceno = ifaces[i]-idesc-bInterfaceNumber;
dv = USB_DO_ATTACH(dev, bdev, parent, uaa, usbd_print,
usbd_submatch);
+
+ if (dev-address == USB_START_ADDR) {
+#if defined(__FreeBSD__)
+device_delete_child(parent, bdev);
+#endif
+return (USBD_NEED_RESET);
+ }
+
if (dv != NULL) {
dev-subdevs[found++] = dv;
dev-subdevs[found] = 0;
@@ -958,7 +970,7 @@
* and attach a driver.
*/
usbd_status
-usbd_new_device(device_ptr_t parent, usbd_bus_handle bus, int depth,
+usbd_new_device2(device_ptr_t parent, usbd_bus_handle bus, int depth,
int speed, int port, struct usbd_port *up)
{
usbd_device_handle dev;
@@ -1099,6 +,12 @@
err = usbd_probe_and_attach(parent, dev, port, addr);
if (err) {
+ if (err == USBD_NEED_RESET) {
+ DPRINTFN(1,(usbd_new_device: device needs reset\n));
+ /* must set address back to what it was */
+ dev-address = addr;
+ }
+
usbd_remove_device(dev, up);
return (err);
}
@@ -1106,6 +1124,27 @@
usbd_add_dev_event(USB_EVENT_DEVICE_ATTACH, dev);
return (USBD_NORMAL_COMPLETION);
+}
+
+usbd_status
+usbd_new_device(device_ptr_t parent, usbd_bus_handle bus, int depth,
+ int speed, int ports, struct usbd_port *up)
+{
+ int retry = 0;
+ usbd_status err;
+
+ err = usbd_new_device2(parent, bus, depth, speed, ports, up);
+ while ((err == USBD_NEED_RESET) (retry++ 5)) {
+ DPRINTFN(1,(usb_new_device: re-enumerating device\n));
+ err = usbd_new_device2(parent, bus, depth, speed, ports, up);
+ }
+
+ if (retry == 5) {
+ DPRINTFN(1,(usb_new_device: giving up after 5 tries...\n));
+ return (USBD_NOT_CONFIGURED);
+ }
+
+ return err;
}
usbd_status
diff -ur usb.org/usbdi.h usb/usbdi.h
--- usb.org/usbdi.h Mon May 6 20:23:36 2002
+++ usb/usbdi.h Wed Jan 7 21:45:11 2004
@@ -66,6 +66,7 @@
USBD_SHORT_XFER, /* 16 */
USBD_STALLED, /* 17 */
USBD_INTERRUPTED, /* 18 */
+ USBD_NEED_RESET, /* 19 */
USBD_ERROR_MAX /* must be last */
} usbd_status;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send
Re: USB stack / configuration 0
On Wednesday 07 January 2004 09:07, Bernd Walter wrote: On Wed, Jan 07, 2004 at 05:34:05PM +1030, Daniel O'Connor wrote: On Wednesday 07 January 2004 17:08, Bernd Walter wrote: I don't think it IS a dumb device, there is a USB spec called DFU which covers it and the hosts job is to do the reenumeration. Sparing a transistor to offload the work to the host were its also way more complex to do is dump. If this is part of the Spec, then the spec is dump too. Err yes, this IS USB we're talking about here :) Reead your spec - it's not part of USB itself. As long as there are a lot of usefull devices that use the DFU spec, to me it seems no more than logicle to implement it in FreeBSD, no matter how dumb the system may sound :) usbd_reset_port should do from the USB point of view, but this doesn't trigger Free BSD to do a reconfiguration of the device, which is required after reset. Maybe the following will do instead: usbd_clear_port_feature(dev, port, UHF_PORT_ENABLE) delay(USB_PORT_POWERUP_DELAY); usbd_set_port_feature(dev, port, UHF_PORT_ENABLE) dev and port is that from the hub. Except that would remove power to the port I think.. AFAIK power is independend, but I'm not 100% shure. I have written a driver for Atmel USB WLAN adapters for FreeBSD recently (and still am). The device also needs it's firmware to be uploaded via the DFU interface. The first time the device is plugged in, an internal ROM mask is mapped into code-space of the processor which provides it with only a very basic USB stack that can do enumeration and DFU. Via DFU the host uploads the firmware into RAM. At the end of the upload the host asks the device to manifest the firmware. For the device this means having to switch the ROM image with the RAM image which is impossible while running in the specific processor. Thus the processor tells it's core to map RAM into code-space and resets itself. After that the device will apear again with address = 0. The host then needs to set the address, re-read the device descriptor (it has changes, the device now offers endpoints etc), attach a driver. Btw, a reset can be sent down to a usb device from within a driver with this line of code : usb_port_status_t stat; usbd_reset_port(sc-atuwi_udev-myhub, sc-atuwi_udev-powersrc-portno, stat); For my device driver I have made a small change to the USB Stack and I have introduced the return code USB_ATTACH_NEED_RESET for drivers to tell the USB Stack thee device needs to be re-enumerated. The stack then automatically re-assigns the device it's address, and re-probes for drivers. This way even two seperate drivers could be made : one with the firmware and one with the real driver. Is anyone interrested in a patch maybe? btw2: I have submitted a couple of patches in 2003 (one of witch is almost a year old at this moment), but none of the got comments / commited. Is anyone really working on USB code development / debugging lately? I want to see ALL USB devices working with FreeBSD and am willing to devote my spare-time to achieving this. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atmel WLAN Driver
(to stop cross-posting please 'cc' follow-ups to -questions) On Monday 22 December 2003 19:10, Markus Kovero wrote: Hi. I Have Belkin 11MBps wlan adapter F5D6020 ver.2 that uses atmel chipset. I noticed that support for freebsd hasnt been made yet but I found leenox driver for it. So I thought to ask would it be possible to port leenox driver to freebsd so I could use my wlan pcmcia card. Linux driver I found: http://atmelwlandriver.sourceforge.net/news.html I have been (and still am) working on a FreeBSD driver for the USB version of this adapter. The driver homepage can be found here : http://vitsch.net/bsd/atuwi/ If you want to try to get the PCMCIA version working, you could have a look at the driver to start with, since the device itself is the same, only the interface to it is different. Thanks. Peaceful xmas and happy newyear! Greets Markus Kovero grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Errors in USB subsystem and bktr driver
Hi, I have just filed kern/59290 about an error in all usb ethernet drivers that can crash a system and kern/59289 about small error in an ioctl in the bktr driver. (Both with patch). Anyone interrested in fixing them? grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Release (beta) driver for Atmel USB Wireless LAN adapters
Hi, After about a month of spare time work I have finally come to a point of releasing some software. I have written a driver for the Atmel AT76c503 Wireless LAN adapters. At this moment the driver is capable of sending / receiving in Ad Hoc mode only. If you happen to own one of these adapters, please give the driver a try and let me know what you think of it. (This is my first real kernel driver, so please kick it gently :) You can find the driver here : Driver home page : http://www.vitsch.net/bsd/atuwi/ Release 0.1 file overview : http://www.vitsch.net/bsd/atuwi/0.1/ Or grab the tarball imediately : http://www.vitsch.net/bsd/atuwi/0.1/atuwi-0.1.tar.gz At this moment I have a problem with the driver. After uploading the firmware to the device, the device needs to be resetted. I have the reset-code working, but after the reset the device changes it's descriptors and some kernel buffers/pointers have to be updated with the device. I don't know enough about the usb kernel internals to figure out what I'm doing wrong. That's why I have attached the reset code to this email. If someone could tell me what I'm doing wrong I would be very thankfull. grtz, Daan___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Atmel USB Wireless devices
On Thursday 28 August 2003 15:26, Stuart Walsh wrote: Hi, Firstly, it would be interesting to know if anyone else is working on support for these devices before I get too far into it :) Yes, I have bought a bunch of them about a month ago, and at this moment I have a working driver for them. At this moment it's still a beta which can only do ad-hoc mode, but it works. I've started working on support for the above devices and have had some limited success so far. The device requires two sets of firmware to be uploaded for it to work and I have managed to upload the first firmware but it doesnt seem to want to boot. Any attempts to read the device after uploading firmware result in error code 13(IOERROR). The Linux driver calls usb_reset_device() after uploading the firmware but I can't seem to find an equivelant in FreeBSD. The problem is that the device really dies after uploading the internal firmware. It really needs a reset before it will communicate again. A usb-hub can send a reset signal down it's ports with a call to : usbd_reset_port(sc-atuwi_udev-myhub,sc-atuwi_udev-powersrc-portno,T); After that the atmel processor will start communicating again. But it's usb-address will be set to 0 (as always after a reset). So you will have to (re)set it's address back to what it was before the reset with a call to : usbd_set_address(sc-atuwi_udev,my_old_address); The story gets more complex since the descriptors of the device have changed by the reset. (first it only had a control endpoint, now it also has 2 bulk endpoints). Somehow you'll have to reload the new descriptor to please the kernel. I have come very far in this process, but I am doing something wrong with releasing the old descriptors... So at this moment I use a trick to reset the device. After uploading the internal firmware I unplug the USB connector just far enough for the data-lines to disconnect, but without disconnecting the power-lines. After plugging the device back in the kernel recognizes it again and uploads the external firmware. I'll come back to this thread tomorrow and post some links to my code, but I have to run now. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fetch command sending STDOUT to STDERR
On Friday 01 August 2003 22:54, Peter Elsner wrote: For some time now, I've been using FTP to transfer files from one server to another. I recently decided to update my script to use fetch instead of FTP. For some reason, the fetch command seems to be sending STDOUT messages to STDERR. I have a cron job that runs every 15 minutes and fetches some files, the output from STDIN is: 96 bytes transferred in 0.0 seconds (1.24 MBps) 249 bytes transferred in 0.0 seconds (2.70 MBps) However, I have the STDOUT redirected to a file name in /tmp report.out and STDERR redirected to a file name in /tmp report.err My script then checks to see if report.err is greater than 0 bytes. If it's not, the script exits cleanly (it should), if it is greater than 0 bytes, it sends me an email stating that the file transfer failed, and appends the report.err file. Here is my cron entry: */15 * * * * /home/reports/reports.sh /tmp/reports.out 2/tmp/reports.err For the time being, I've redirected STDERR to /dev/null which will stop the problem. However, if the transfer fails, I won't know about it either... Is this normal for fetch? This won't answer your question, but maybe it will help you. According to the manual page of fetch, fetch returns zero on successfull completion so maybe you could check the return value of the fetch operation something like this : fetch -o /some/file http://some.url/ 2/tmp/report.err || do-mail-thing (the do-mail-thing command will only be executed if the return value of fetch is non-zero) grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: differences in USB support between FreeBSD 4.x and 5.x ?
On Monday 21 July 2003 15:00, Bernd Walter wrote: On Mon, Jul 21, 2003 at 09:18:42AM +0200, Marco Molteni wrote: [I sent the same message to [EMAIL PROTECTED], but since that list seems not very active, I am asking here too] Hi all, the subject says it all. I am considering using FreeBSD for a robotics project, and I am thinking of using 4.x for stability. But, since we will probably use USB a lot, I am wondering if maybe 5.x is a better choice. I believe 4.x has all you need for your project. If you really find a problem then the missing part can be MFC'ed. Both 4.x and 5.x have a pointer-bug in the ugen-driver causing memory to be overwritten outside a buffer when using isochronous transfers. I have sent a PR about this (with patch) back in April. **(: HINT HINT :) ** ( pr kern/51186 : http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern%2F51186 ) thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: modern (usb) webcam support?
On Thursday 20 February 2003 01:16, you wrote: My searches for information on webcam have not found much, except for some sites which say FreeBSD does not support USB web cameras. Is anyone currently working on support for this? Does anyone have any ideas about where one could go to get information about where to start if one was to start writing a driver? At this moment I am writing a userland (ugen) interface for the Logitech Quickcam Zoom. I already get a YUV-packet picture out of the cam at this moment. It's still far from finished, but i'm working on in. Since the Logitech cam uses a module made by Philips, this driver will also support a range of Philips USB webcams. (at least, that's my goal :) (I am about to buy a webcam for use in windows, it would be nice if I could choose a webcam which someone is either writing a driver for or knows where i coudl get information on them so that I could try and write one). Any info appreciated! - jacob ___ Jacob RhodenPhone: +61 3 9844 6102 ITS DivisionEmail: [EMAIL PROTECTED] Melbourne University Mobile: +61 403 788 386 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message grtz, Daan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Asus/PR-DLSR smp hangs on boot
On Wednesday 08 January 2003 10:21, you wrote: hi, I have yet another dual box to test, Asus Dual Intel/Xeon, this one came preconfigured with 4.7 Release, and 'sort of works' - using the 1Giga ethernet is problematic. The latest 4.7 stable hangs on boot - just after SMP: AP CPU #1 Launched! btw, the -release hangs here for about 20 seconds, then goes on ok. here are 2 logs: ftp://ftp/users/danny/freebsd/logs/release.log is from a successfull boot ftp://ftp/users/danny/freebsd/logs/stable.log is from a failed boot. I don't think I know the answer to the freezing problem, but I can help others that might know to find your logs-files : ftp://ftp.cs.huji.ac.il/users/danny/freebsd/logs/release.log ftp://ftp.cs.huji.ac.il/users/danny/freebsd/logs/stable.log (You forgot the domain, guessed it from the email-address) thanks, danny Grtz, Daan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
