Trouble with copyout, memcpy....
Hey list,I currently code a driver under Current 8.0 for Current 8.0.But there
are some problems with kernel/user-space interaction.I've the following
structure:struct daq_kitinfo { uint32_t ki_maxdata; uint32_t
ki_flags; uint32_t ki_rng_type; int ki_type; int
ki_nchan; int ki_len_chanl;};The above structure is
used in my user-space app:int main(void) { struct daq_kitinfo *info;
struct daq_kit kit; int fd, size; ... ... ...
/* * At this point I'll
try to alloc memory. Notice that * the size i dependet from another
struct entry. */ size = sizeof(*info) * kit.k_nkits; info
= malloc(size); if (info == NULL) exit(ENOMEM);
/* * The next step is to call the drivers ioctl() interface
* (the reason for that is described below). */ if (ioctl(fd,
DAQ_KITINFO, info)) { printf("errno: %d\n", errno);
exit(errno); } printf("[ki_nchan] %d\n", ki_nchan);
... ... return (0);}and inside the driver (put it
simply):static intmy_ioctl(struct cdev *dev, u_long cmd, caddr_t
arg, int flags, struct thread *td){ struct daq_kitinfo *info;
struct daq_kit = dev->si_drv1; int size; ... /* Do
something useful e.g mutex'ing... */ ... /* The same as in
user-space... */ size = sizeof(*info) * kit.k_nkits; info =
malloc(sz, M_DAQ, M_NOWAIT | M_ZERO); if (info == NULL)
/* * Here I want to copy struct info from kernel to
user-space. * If i use memcpy, the result is that the system hangs
* and I need to reboot the machine. OK, I thought * copyout() should
be able to do the job for me... */ if (copyout(info, arg, sz))
/*
* Fuc[k-k] i still come inside this block. I always
* get an EFAULT error. */}I really don't know what I should
do to let the driver workingproperly. The driver should grap some
informations/attributes,and fill up the info structure, so we can copy the
filled info structto the user's app.I hope somebody can help me to resolve that
problem.Ah, the corresponding ioctl is:#define GRP
'd'#define DAQ_KITINFO _IOR(GRP, 3, struct daq_kitinfo)Thanks for
attention and greatz from germanyMG
___
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"
Trouble with copyout, memcpy.... Plain-Text version =)
Hey list,
I currently code a driver under Current 8.0 for Current 8.0.
But there are some problems with kernel/user-space interaction.
I've the following structure:
struct daq_kitinfo {
uint32_t ki_maxdata;
uint32_t ki_flags;
uint32_t ki_rng_type;
int ki_type;
int ki_nchan;
int ki_len_chanl;
};
The above structure is used in my user-space app:
int main(void) {
struct daq_kitinfo *info;
struct daq_kit kit;
int fd, size;
...
...
...
/*
* At this point I'll try to alloc memory. Notice that
* the size i dependet from another struct entry.
*/
size = sizeof(*info) * kit.k_nkits;
info = malloc(size);
if (info == NULL)
exit(ENOMEM);
/*
* The next step is to call the drivers ioctl() interface
* (the reason for that is described below).
*/
if (ioctl(fd, DAQ_KITINFO, info)) {
printf("errno: %d\n", errno);
exit(errno);
}
printf("[ki_nchan] %d\n", info.ki_nchan);
...
...
return (0);
}
and inside the driver (put it simply):
static int
my_ioctl(struct cdev *dev, u_long cmd, caddr_t arg, int flags,
struct thread *td)
{
struct daq_kitinfo *info;
struct daq_kit = dev->si_drv1;
int size;
...
/* Do something useful e.g mutex'ing... */
...
/* The same as in user-space... */
size = sizeof(*info) * kit.k_nkits;
info = malloc(sz, M_DAQ, M_NOWAIT | M_ZERO);
if (info == NULL)
/*
* Here I want to copy struct info from kernel to user-space.
* If i use memcpy, the result is that the system hangs
* and I need to reboot the machine. OK, I thought
* copyout() should be able to do the job for me...
*/
if (copyout(info, arg, sz))
/*
* Fuc[k-k] i still come inside this block. I always
* get an EFAULT error.
*/
}
I really don't know what I should do to let the driver working
properly. The driver should grap some informations/attributes,
and fill up the info structure, so we can copy the filled info struct
to the user's app.
I hope somebody can help me to resolve that problem.
Ah, the corresponding ioctl is:
#define GRP 'd'
#define DAQ_KITINFO _IOR(GRP, 3, struct daq_kitinfo)
Thanks for attention and greatz from germany
MG
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Trouble with copyout, memcpy.... Plain-Text version =)
Leunam Elebek writes:
> /* The same as in user-space... */
> size = sizeof(*info) * kit.k_nkits;
> info = malloc(sz, M_DAQ, M_NOWAIT | M_ZERO);
You shouldn't use M_NOWAIT unless there is absolutely no way around it.
> if (info == NULL)
>
Unnecessary if you use M_WAITOK instead of M_NOWAIT.
> /*
> * Here I want to copy struct info from kernel to user-space.
> * If i use memcpy, the result is that the system hangs
> * and I need to reboot the machine. OK, I thought
> * copyout() should be able to do the job for me...
> */
> if (copyout(info, arg, sz))
Nope, ioctl() takes care of the copyin() / copyout(). At this point,
arg is a pointer to a malloc()ed buffer of the right size (as specified
by the definition of DAQ_KITINFO).
> /*
> * Fuc[k-k] i still come inside this block. I always
> * get an EFAULT error.
> */
This means that either a) info doesn't point where you think it does, b)
arg doesn't point where you think it does, or c) sz doesn't have the
value you think it does.
In this case, it's a combination of the latter two: arg points to a
kernel buffer, so the use of copyout(9) is inappropriate, but in
addition, the size of that buffer is sizeof(daq_kitinfo), and you're
trying to copy far more. You need to rethink your interface: either
return only one struct daq_kitinfo per ioctl() call, or pass in a struct
that contains a pointer to a userland buffer and a length, or use
something else than ioctl(2).
option 2 would be something like:
struct daq_ioctl {
struct daq_kitinfo *info;
int nkits;
};
#define GRP'd'
#define DAQ_KITINFO_IOWR(GRP, 3, struct daq_ioctl)
static int
my_ioctl(struct cdev *dev, u_long cmd, caddr_t arg, int flags, struct thread
*td)
{
struct daq_ioctl *di = (struct daq_ioctl *)arg;
struct daq_kitinfo *info;
struct daq_kit kit;
int nkits, ret;
/* ... */
nkits = (kit.k_nkits > di->nkits) ? di->nkits : kit.k_nkits;
info = malloc(nkits * sizeof(struct daq_kitinfo))
/* ... */
ret = copyout(info, di->info, nkits * sizeof(struct daq_kitinfo));
/* let userland know what it got */
if (ret == 0)
di->nkits = nkits;
return (ret);
}
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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"
Help debugging: Fatal kernel mode data abort: 'External Linefetch Abort (P)'
Hi, I am working on getting FreeBSD to boot on a new ARM based board, and am hitting this issue any time I load a driver for the PCI based devices on the board. My current code can be found here: http://www.tomjudge.com/tmp/em7210.patch Here is the back trace of the problem (which i can repeat with em and ohci drivers): RedBoot> load -b 0x01008000 kernel Using default protocol (TFTP) Address offset = 0x4000 Entry point: 0x01008100, address range: 0x01008000-0x01349e28 RedBoot> go KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #12: Sat Sep 26 05:00:06 UTC 2009 r...@rita.nodomain:/data/arm_build/arm/usr/src/sys/EM-7210 CPU: i80219 400MHz step A-0 (XScale core) DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way Instruction cache 32KB/32B 32-way write-back-locking Data cache real memory = 536870912 (512 MB) avail memory = 503738368 (480 MB) iq0: on motherboard obio0 on iq0 uart0: <16550 or compatible> on obio0 uart0: [FILTER] uart0: console (115200,n,8,1) itimer0: on iq0 iopwdog0: on iq0 pcib0: on iq0 pci0: on pcib0 No mapping for 0/5/0/ No mapping for 0/5/1/ No mapping for 0/5/2/ pci0: at device 1.0 (no driver attached) pci0: at device 2.0 (no driver attached) atapci0: mem 0x8-0x80fff irq 27 at device 3.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 Fatal kernel mode data abort: 'External Linefetch Abort (P)' trapframe: 0xc00faaf0 FSR=0406, FAR=Invalid, spsr=60d3 r0 =c13e2c00, r1 =cd5bc000, r2 =0004, r3 =c13e2d7c r4 =c13e2c00, r5 =cd5bc000, r6 =c1298290, r7 =c1388800 r8 =, r9 =0009, r10=c13d8c00, r11=c00fab58 r12=c00fab24, ssp=c00fab3c, slr=c102389c, pc =c1023898 [thread pid 0 tid 10 ] Stopped at ata_ahci_chipinit+0x4d68: ldr r15, [r3, #0x024] db> bt Tracing pid 0 tid 10 td 0xc134dca0 db_trace_thread() at db_trace_thread+0xc scp=0xc129c68c rlv=0xc100d0f0 (db_command_init+0x2a8) rsp=0xc00fa7ec rfp=0xc00fa808 r10=0x0001 r9=0xc13537f4 r8=0xc134b0c4 r7=0x0062 r6=0x0002 r5=0x0010 r4=0xc134dca0 db_command_init() at db_command_init+0x1d0 scp=0xc100d018 rlv=0xc100cba0 (db_skip_to_eol+0x49c) rsp=0xc00fa80c rfp=0xc00fa8b0 r5=0x r4=0xc1327938 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc100c8d4 rlv=0xc100cd0c (db_command_loop+0x60) rsp=0xc00fa8b4 rfp=0xc00fa8c0 r10=0x r8=0x0406 r7=0xc00faaf0 r6=0xc13537f0 r5=0x60d3 r4=0xc00fa8cc db_command_loop() at db_command_loop+0xc scp=0xc100ccb8 rlv=0xc100f050 (X_db_sym_numargs+0xf4) rsp=0xc00fa8c4 rfp=0xc00fa9e0 X_db_sym_numargs() at X_db_sym_numargs+0x14 scp=0xc100ef70 rlv=0xc1106e40 (kdb_trap+0xa4) rsp=0xc00fa9e4 rfp=0xc00faa0c r4=0x00c0 kdb_trap() at kdb_trap+0xc scp=0xc1106da8 rlv=0xc12acb44 (badaddr_read+0x280) rsp=0xc00faa10 rfp=0xc00faa2c r10=0x r9=0x0009 r8=0xc00faaf0 r7=0x0406 r6=0x r5=0x0406 r4=0xc00faaf0 badaddr_read() at badaddr_read+0xfc scp=0xc12ac9c0 rlv=0xc12acfdc (prefetch_abort_handler+0x440) rsp=0xc00faa30 rfp=0xc00faa50 r6=0xc134dca0 r5=0xc00faef8 r4=0xc00faaf0 prefetch_abort_handler() at prefetch_abort_handler+0x378 scp=0xc12acf14 rlv=0xc12ad1a8 (data_abort_handler+0x110) rsp=0xc00faa54 rfp=0xc00faaec r7=0xc134dca0 r6=0xc1298290 r5=0xc00faef8 r4=0xc134d9d8 data_abort_handler() at data_abort_handler+0xc scp=0xc12ad0a4 rlv=0xc129e0c8 (address_exception_entry+0x50) rsp=0xc00faaf0 rfp=0xc00fab58 r10=0xc13d8c00 r9=0x0009 r8=0x r7=0xc1388800 r6=0xc1298290 r5=0x1004 r4=0xc13e2c00 ata_ahci_chipinit() at ata_ahci_chipinit+0x4c44 scp=0xc1023774 rlv=0xc101b664 (ata_mode2idx+0x464) rsp=0xc00fab5c rfp=0xc00fab78 r7=0xc1391900 r6=0xc13d8c00 r5=0xc1388800 r4=0xc13a01b0 ata_mode2idx() at ata_mode2idx+0x3ec scp=0xc101b5ec rlv=0xc1101a98 (device_attach+0x2c8) rsp=0xc00fab7c rfp=0xc00fabb8 r7=0xc1100140 r6=0xc13d8c4c r5=0x8000 r4=0xc1383080 device_attach() at device_attach+0xc scp=0xc11017dc rlv=0xc1102e5c (device_probe_and_attach+0x34) rsp=0xc00fabbc rfp=0xc00fabcc r10=0xc1383080 r8=0x r7=0xc1100140 r6=0xc1383080 r5=0xc1391900 r4=0xc13d8c00 device_probe_and_attach() at device_probe_and_attach+0xc scp=0xc1102e34 rlv=0xc1102e80 (bus_generic_attach+0x20) rsp=0xc00fabd0 rfp=0xc00fabe0 r4=0xc13d8c00 bus_generic_attach() at bus_generic_attach+0xc scp=0xc1102e6c rlv=0xc101d11c (ata_pci_attach+0x2a4) rsp=0xc00fabe4 rfp=0xc00fac0c r4=0x0004 ata_pci_attach() at ata_pci_attach+0xc scp=0xc101ce84 rlv=0xc1101a98 (device_attach+0x2c8
Re: Help debugging: Fatal kernel mode data abort: 'External Linefetch Abort (P)'
On Mon, Sep 28, 2009 at 06:55:38PM +, Tom Judge wrote: > Hi, > > I am working on getting FreeBSD to boot on a new ARM based board, and am > hitting this issue any time I load a driver for the PCI based devices on > the board. > > My current code can be found here: > > http://www.tomjudge.com/tmp/em7210.patch > Hi Tom, My guess is, you should include std.i80219 instead of std.i80321 in std.em7210. If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to check if the board is host or not will be used, and will wrongly assume it is not, and thus won't map the PCI mem correctly. Regards, Olivier ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help debugging: Fatal kernel mode data abort: 'External Linefetch Abort (P)'
Olivier Houchard wrote: On Mon, Sep 28, 2009 at 06:55:38PM +, Tom Judge wrote: Hi, I am working on getting FreeBSD to boot on a new ARM based board, and am hitting this issue any time I load a driver for the PCI based devices on the board. My current code can be found here: http://www.tomjudge.com/tmp/em7210.patch Hi Tom, My guess is, you should include std.i80219 instead of std.i80321 in std.em7210. If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to check if the board is host or not will be used, and will wrongly assume it is not, and thus won't map the PCI mem correctly. Hi Olivier, I have switched out the std file and am now using std.i80219 but am still having issues. I think the problems are the pci memory mappings in the controller devices. On linux em0 gets mapped as follows: cd \:00\:01.0/ # ls class devicelocal_cpussubsystem_device configdriverresource subsystem_vendor detach_state irq rom vendor # cat resource 0x8000 0x8001 0x0200 0x8002 0x8003 0x0200 0xfe00 0xfe3f 0x0101 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x8004 0x8005 0x7200 # Where as on FreeBSD I am seeing this: em0: port 0xfe40-0xfe40003f mem 0-0x1,0x2-0x3 irq 29 at device 1.0 on pci0 Seems that I am missing the 0x800 off the front of the PCI memory mappings. I have confirmed this with the ata driver also and see the same issues. Where should I be looking to fix this? Thanks Tom ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Help debugging: Fatal kernel mode data abort: 'External Linefetch Abort (P)'
Tom Judge wrote: Olivier Houchard wrote: On Mon, Sep 28, 2009 at 06:55:38PM +, Tom Judge wrote: Hi, I am working on getting FreeBSD to boot on a new ARM based board, and am hitting this issue any time I load a driver for the PCI based devices on the board. My current code can be found here: http://www.tomjudge.com/tmp/em7210.patch Hi Tom, My guess is, you should include std.i80219 instead of std.i80321 in std.em7210. If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to check if the board is host or not will be used, and will wrongly assume it is not, and thus won't map the PCI mem correctly. Hi Olivier, I have switched out the std file and am now using std.i80219 but am still having issues. I think the problems are the pci memory mappings in the controller devices. On linux em0 gets mapped as follows: cd \:00\:01.0/ # ls class devicelocal_cpussubsystem_device configdriverresource subsystem_vendor detach_state irq rom vendor # cat resource 0x8000 0x8001 0x0200 0x8002 0x8003 0x0200 0xfe00 0xfe3f 0x0101 0x 0x 0x 0x 0x 0x 0x 0x 0x 0x8004 0x8005 0x7200 # Where as on FreeBSD I am seeing this: em0: port 0xfe40-0xfe40003f mem 0-0x1,0x2-0x3 irq 29 at device 1.0 on pci0 Seems that I am missing the 0x800 off the front of the PCI memory mappings. I have confirmed this with the ata driver also and see the same issues. Where should I be looking to fix this? Forgot to include the output from VERBOSE_INIT_ARM iq0: on motherboard i80321: BAR0 = 2004. BAR1 = 4004. i80219: BAR0 = 2000. BAR1 = 4000. i80321: SBDR = 0xa000 SBR0 = 0x0018 SBR1 = 0x0020 i80321: BANK0 = 0x1000 BANK1 = 0x1000 i80321: Reserve space for private devices (Inbound Window 1) hi:0x lo:0x800c xlate:0x8000 size:0x0400 i80321: RAM access (Inbound Window 2) hi:0x lo:0xa00c xlate:0xa000 size:0x2000 obio0 on iq0 uart0: <16550 or compatible> on obio0 ___ 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"
