Re: sym(4) broken on amd64 (Time to port new driver?)
Sergey N. Voronkov wrote: Looks like it is broken for a while - _sym_calloc2: failed to allocate HCB is always there... And... Looks like Gerard Roudier havn't more interest in maintaining this driver - there is the second generation of the original driver into linux source three since 2001, which is newer ported to FreeBSD by the author. And FreeBSD hooks was removed from the driver code... May be it is a time to port siop(4) from NetBSD? No. I'm working on fixing this right now. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Writing a driver for a card reader controller - how?
Hi there, (Trying here now after no response on -drivers... If nothing happens here, I guess I'll stop bothering you.) I am writing a device driver for a card reader controller which is installed in my notebook, using the Winbond W83L518D chip. It's FreeBSD 6.0-STABLE running there now, though I started programming under 5.4-R, and the symptoms have not changed since then. However, when I attach it, it seems to allocate the resources port 0-0x7 irq 0 drq 4 on acpi0 which seems strange to me -- accessing registers in the respective SYS_RES_IOPORT seems to work, though. Now, as far as I understand the datasheet for the controller, I have to use another I/O port to access the SD card itself, to check if one is there, and finally to access it. How I do this, though, I have no idea. The datasheet lists two configuration registers that select SD Card interface base address on 8-byte boundary - but will my driver have to program an address into those registers? Does the bus framework somehow handle this? Does even BIOS do this? Or will I have to write one driver for the controller, have that act as a bus driver, and attach some SD card driver to that one? Maybe someone is willing to spend some time having a look at the datasheet and what I have done so far, and give me a little (or larger) clue-up... In return, I promise to write some documentation about how I have done it once it is ready, just in case someone else faces similar problems. A pointer to some driver programming documentation I have missed so far would be just as nice, of course. So far, I have tried using fdc and ppc as a guideline (after having found the spkr driver to be a bit too simple), and I _think_ I am doing just as those drivers do probing and resource allocation, but somehow they work, and mine does not. Link to the datasheet and some more description of what I have done so far (including my current state of source code) are at http://projects.thiemo.net/WbcrDriver Many thanks, and best regards, Thiemo -- Query a PGP key server (e.g. http://www.pgp.net/) for my public key 41068629. Strange sender address? Please see http://www.thiemo.net/misc/list-mail.shtml ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Writing a driver for a card reader controller - how?
On Wed, 23 Nov 2005 19:50, Thiemo Nordenholz wrote: I am writing a device driver for a card reader controller which is installed in my notebook, using the Winbond W83L518D chip. It's FreeBSD 6.0-STABLE running there now, though I started programming under 5.4-R, and the symptoms have not changed since then. However, when I attach it, it seems to allocate the resources port 0-0x7 irq 0 drq 4 on acpi0 which seems strange to me -- accessing registers in the respective SYS_RES_IOPORT seems to work, though. It looks really weird to me.. I can't imagine it's _really_ at 0x0 :) Looking at your page I think you should try attaching to the ISA 'version' - you should be able to key off it's PnP entry I think. I don't know if there is extra magic with the acpi 'bus' though, or what it really means.. Now, as far as I understand the datasheet for the controller, I have to use another I/O port to access the SD card itself, to check if one is there, and finally to access it. How I do this, though, I have no idea. The datasheet lists two configuration registers that select SD Card interface base address on 8-byte boundary - but will my driver have to program an address into those registers? Does the bus framework somehow handle this? Does even BIOS do this? Or will I have to write one driver for the controller, have that act as a bus driver, and attach some SD card driver to that one? I would say you'd have to allocate some memory (probably low down) then write it's address into those registers, then you will be able to read the card via that address. I've only hacked on ISA and PCI drivers and they aren't nearly as weird as that hardware sounds ;) Your next problem will be how to present the SD card to the OS.. Perhaps you can present it as a block device I guess. Link to the datasheet and some more description of what I have done so far (including my current state of source code) are at http://projects.thiemo.net/WbcrDriver -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpEnmaZj5RdC.pgp Description: PGP signature
Re: getdirentries_args and other kernel syscall structures
On Tue, Nov 22, 2005 at 08:32:10PM -0800, Daniel Rudy wrote:
Ok, I'va got a little question here. In the structure
getdirentries_args, there seems to be duplicated fields that I'm not
entirely sure what they do. Here's the definition of a structure
verbatim from sys/sysproto.h:
struct getdirentries_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)];
char count_l_[PADL_(u_int)]; u_int count; char
count_r_[PADR_(u_int)];
char basep_l_[PADL_(long *)]; long * basep; char
basep_r_[PADR_(long *)];
};
Now my question is what does the l and r variables do? It seems that
they do something with padding the data based on the endian of the
machine? I look through this header file, and I see all the structures
have similar constructs. Is it something that can be safely ignored?
This file is automatically generated by makesyscalls.sh. The l and r
variables are a hack to correctly the member between them. One of PADL_
or PADR_ always evalutes to 0, the other one to the needed padding,
depending on the passed type. This is unfortunate because it relies on
the GCC extension to accept 0-sized arrays. I'd love to fix that but
couldn't come up with something that isn't very involved.
Stefan
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getdirentries_args and other kernel syscall structures
2005/11/23, Daniel Rudy [EMAIL PROTECTED]:
Ok, I'va got a little question here. In the structure
getdirentries_args, there seems to be duplicated fields that I'm not
entirely sure what they do. Here's the definition of a structure
verbatim from sys/sysproto.h:
struct getdirentries_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)];
char count_l_[PADL_(u_int)]; u_int count; char
count_r_[PADR_(u_int)];
char basep_l_[PADL_(long *)]; long * basep; char
basep_r_[PADR_(long *)];
};
Now my question is what does the l and r variables do? It seems that
they do something with padding the data based on the endian of the
machine? I look through this header file, and I see all the structures
have similar constructs. Is it something that can be safely ignored
It just pads in the right way (according with endianism) the structure
to the right word. For example, x86 gots sizeof(long *) == 4. If you
want to have a syscall structure like that:
struct example_sys
{
char f;
short p;
int g;
};
it is misaligned. In order to get a proper padded structure (all 32
bits entries) to speed-up accesses to the members, this little trick
is used.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
even more stats for your pleasure
Number crunchers, alert! I've put together never before presented statistics related to our bug tracking system, GNATS. PR Arrival Rates http://www.oook.cz/bsd/prstats/arriverates.html PR Closing Rates http://www.oook.cz/bsd/prstats/closerates.html PR New Flow http://www.oook.cz/bsd/prstats/rates.html See how much PRs is flowing in and getting resolved, per month, per category. Be sure to click the headers to see detailed numbers for your favourite category. October 2005 was second busiest month ever for us, ports people, both in arrivals and resolving. We got to almost 40 PRs/day rate, and did rather well, closing 98% of the amount of what arrived. Perky-san quickly created a nice visualization of these charts: http://people.freebsd.org/~perky/arrivalrate.png http://people.freebsd.org/~perky/arrivalrate-except-ports.png -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] The Linimon's Rule: The More You Close, The More Will Come signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: a puzzle about FreeBSD
On Sat, Nov 19, 2005 at 09:51:58PM +0800, ?? wrote:
I read the source code of a project. I don??t understand SYSCTL_IN macro and
SYSCTL_PROC macro. I want to know when my function registered in SYSCTL_PROC
is called.
This sysctl handler is called, for example, from __sysctl -
userland_sysctl - sysctl_root as oid_handler, which is setuped,
when SYSCTL_PROC declared struct sysctl_oid{}.
SYSCTL_IN/OUT are used for copying to/from one buffer to another
buffer with advancing pointers and offsets of buffers. Since
there are two spaces userland and kernel, but interface should
be general, there are two functions oldfunc and newfunc in struct
sysctl_req{}, which are defined to sysctl_{new,old}_{kernel,user},
depending from which space it is necessary to make sysctl call.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getdirentries_args and other kernel syscall structures
At about the time of 11/23/2005 3:23 AM, rookie stated the following:
2005/11/23, Daniel Rudy [EMAIL PROTECTED]:
Ok, I'va got a little question here. In the structure
getdirentries_args, there seems to be duplicated fields that I'm not
entirely sure what they do. Here's the definition of a structure
verbatim from sys/sysproto.h:
struct getdirentries_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)];
char count_l_[PADL_(u_int)]; u_int count; char
count_r_[PADR_(u_int)];
char basep_l_[PADL_(long *)]; long * basep; char
basep_r_[PADR_(long *)];
};
Now my question is what does the l and r variables do? It seems that
they do something with padding the data based on the endian of the
machine? I look through this header file, and I see all the structures
have similar constructs. Is it something that can be safely ignored
It just pads in the right way (according with endianism) the structure
to the right word. For example, x86 gots sizeof(long *) == 4. If you
want to have a syscall structure like that:
struct example_sys
{
char f;
short p;
int g;
};
it is misaligned. In order to get a proper padded structure (all 32
bits entries) to speed-up accesses to the members, this little trick
is used.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
Ah, a performance trick. I get it now. Thanks.
--
Daniel Rudy
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getdirentries_args and other kernel syscall structures
At about the time of 11/23/2005 3:11 AM, Stefan Farfeleder stated the
following:
On Tue, Nov 22, 2005 at 08:32:10PM -0800, Daniel Rudy wrote:
Ok, I'va got a little question here. In the structure
getdirentries_args, there seems to be duplicated fields that I'm not
entirely sure what they do. Here's the definition of a structure
verbatim from sys/sysproto.h:
struct getdirentries_args {
char fd_l_[PADL_(int)]; int fd; char fd_r_[PADR_(int)];
char buf_l_[PADL_(char *)]; char * buf; char buf_r_[PADR_(char *)];
char count_l_[PADL_(u_int)]; u_int count; char
count_r_[PADR_(u_int)];
char basep_l_[PADL_(long *)]; long * basep; char
basep_r_[PADR_(long *)];
};
Now my question is what does the l and r variables do? It seems that
they do something with padding the data based on the endian of the
machine? I look through this header file, and I see all the structures
have similar constructs. Is it something that can be safely ignored?
This file is automatically generated by makesyscalls.sh. The l and r
variables are a hack to correctly the member between them. One of PADL_
or PADR_ always evalutes to 0, the other one to the needed padding,
depending on the passed type. This is unfortunate because it relies on
the GCC extension to accept 0-sized arrays.
The file is automatically generated? Now that I think about it, I
remember seeing something to that effect in the header file...
I'd love to fix that but couldn't come up with something that
isn't very involved.
I have an idea about that...
Why not do something like this:
#define PAD_(t) (sizeof(register_t) = sizeof(t) ? \
0 : sizeof(register_t) - sizeof(t))
struct getdirentries_args {
#if BYTE_ORDER == LITTLE_ENDIAN
int fd; char fd_r_[PAD_(int)];
char * buf; char buf_r_[PAD_(char *)];
u_int count; char count_r_[PAD_(u_int)];
long * basep; char basep_r_[PAD_(long *)];
#else
char fd_l_[PAD_(int)]; int fd;
char buf_l_[PAD_(char *)]; char * buf;
char count_l_[PAD_(u_int)]; u_int count;
char basep_l_[PAD_(long *)]; long * basep;
#endif
};
This way, you only pad what you need based on the endian of the machine,
and the one that isn't used is stripped out by the preprocessor. And as
a bonus, it's pretty clear as to what is going on and not as confusing.
I haven't looked at the script that generates this file, but I don't
see how hard it could be to modify the script to do something like this.
Yes, the header file will be larger, but only half will be used.
Now, onto the actuall problem that I have been having with the
getdirentries syscall. It has to do with the buf member. The buffer
seems to be 4K, which we all know is the size of 1 page on IA32
hardware. The problem is that I can only get data for the first struct
dirent record. Subsequest records are null. The first record
represents the '.' directory. According to the man page, the d_reclen
member specifies the length of the current record, so the following code
should be able to walk from one record to another:
static int new_getdirentries(struct thread *t, struct getdirentries_args
*uap)
{
unsigned int buffsize;
unsigned int n;
int flag;
struct dirent *dirp_start;
struct dirent *dirp_current;
struct dirent *dirp2;
struct dirent *dirp3;
int result;
int status;
/* issue the syscall */
result = getdirentries(t, uap);
printf(getdirentries result %d\n, result);
if (result != 0) return(result);
/* and check the buffer */
dirp_start = (struct dirent *)uap-buf;
if (dirp_start == NULL) return(result);
/* do we have work to do? */
if (dirp_start-d_namlen 0)
{
/* get our buffer size */
buffsize = uap-count;
/* allocate memory buffer in kernel space */
MALLOC(dirp2, struct dirent *, buffsize, M_DIRP2, M_NOWAIT);
if (dirp2 == NULL) return(result);
/* copy data into kernel space */
copyin(uap-buf, dirp2, buffsize);
/* setup pointers */
dirp_start = dirp2;
dirp_current = dirp_start;
/* set the flag */
flag = 0;
n = buffsize;
r = 0;
printf(buffsize %u; dirent size %d; getdirent %d\n, buffsize,
sizeof(struct dirent),
sizeof(struct getdirentries_args));
/* now walk through the dirent structures */
while (flag == 0)
{
/* decrement the used buffer length */
n -= dirp_current-d_reclen;
printf(**BEFORE\n);
printf(n %u; r %u\n, n, r);
printf(name %s; len %hhu; reclen %hu\n, dirp_current-d_name,
dirp_current-d_namlen, dirp_current-d_reclen);
/* set next pointer */
dirp3 = dirp_current + dirp_current-d_reclen;
dirp_current = dirp3;
printf(**AFTER\n);
printf(n %u; r %u\n, n, r);
printf(name %s; len %hhu;
Re: Question about closeing and opening stdin
On Wednesday 23 November 2005 11:21, Joan Picanyol i Puig wrote: [private reply, I'm 100% unsure I understand what you want] * Michael C. Shultz [EMAIL PROTECTED] [20051122 19:58]: How do I close then open stdin and keep it set to the same terminal as when it was closed? ? If it's closed, you've lost your file descriptor. and it works in this instance of the program, but if a second instance is started the second instance can't close stdin. I seems like you want file descriptor passing. You can pass fd's over pipes. qvb -- pica Here is the solution that finally worked in my case: local_stdin = fopen( /dev/stdin, r ); answer = getc( local_stdin ); if timeout: fclose( local_stdin ); After answer is handled I then just: fclose( local_stdin ); and leave it closed untill needed again I am able to open and close this local_stdin without adversly affecting the global stdin, don't know if it's the right thing to do but it works with every test I've thrown at it so far. -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
libutil properties_read() bug: patch for review
Hi, I recently hit upon a bug in sysinstall, getting an Invalid realloc size of 0 error that caused sysinstall to terminate. I eventually tracked it down to a bug in the properties_read() function of libutil, which occurs only when reading a properties file of 4096 bytes or greater. This is because libutil discards its current state when the buffer runs out (4096 bytes) and it must refill the buffer, causing the properties file (*.inf) to be incorrectly read. I've made a patch that's attached to the PR I filed, PR 89181, but was hoping to get some extra eyes on the patch to make sure that there's nothing amiss with the patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=89181 Hopefully someone can review this and see about getting it committed for 6.1! -Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
6.0-STABLE powerd: eating my keyboard input
Hi all, I just upgraded from 6.0-RELEASE to -STABLE today (FreeBSD 6.0-STABLE #0: Thu Nov 24 00:40:48 WET 2005). After the upgrade I couldn't login anymore, so I thought I probably erased master.passwd by mistake with mergemaster, and rebooted into single user mode. Here I reset both root and my user account password, and processed to multiuser, only to fail the login again. Both on KDE and console. I rebooted again into single user, and changed both password to 3 characters. Now I could login, but every word I typed would have some letters wiped out (that was why the login was failing, it was eating my password). A quick 'top' inspection showed powerd using ~30% CPU, which is abnormal. I killed it, and voila! No more letter-eating. I started it again, and back to the same. powerd has always worked fine, it started behaving like this when I upgraded just an hour ago. This is a centrino laptop from acer. Comments, suggestions ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Is there disk blocks cleaning function in FreeBSD6.0?
Hello, everyone. I used to find VOP_FREEBLK macro cleaning the content of disk blocks of a file in 5.4, however I cannot find any kind of these operations doing the same thing in 6.0release. I wonder if there is any function or macro which will clean the data blocks after the file containing these blocks is deleted in 6.0release. Does anybody have any idea about this issue? thanks Zhou Bo Wen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
