headers
lepingouin.tux | 1 Aug 2005 11:04
Favicon

Re: using usb HID under netBSD 2.0.2

Michael wrote:

>Hello,
>
>  
>
>>There are lots of mailing list for netbsd and sorry if it's not the
>>good list !
>>    
>>
>
>We'll see...
>
>  
>
>>I installed netbsd 2.0.2 with the iso cd and I want to make an 
>>application to read and write on USB-HID device.
>>
>>I read, for use HID devices I have to use the device file uhidx !
>>    
>>
>
>... with x being a number of some sort. See man uhid and man uhidev.
>
>  
>
>>But netbsd seems to not reconize my device, and i have no usb 
>>informations under dmesg !!
>>    
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Ritter | 1 Aug 2005 21:59
Picon
Favicon

Re: SoC: NDIS

Hi, thanks for your response :-)

> Actually, the segment registers look normal for NetBSD purposes (ignore
> the upper bits of what gdb says they are).
>
> I'm not quite sure what gdb disassembles as "jmp ds:XXXXXX". It might
> just be a plain pointer jump, with the pointer being at 0xc0a5d548. What
> is the value at address 0xc0a5d548? What are the bytes in the jmp
> instruction?

I'm not sure how many bytes are in the jump instruction, is this what you
wanted?

(gdb) x/i $pc
0xc0a5d410 <drv_data+252356>:   jmp    ds:0xc0a5d548
(gdb) x/8x $pc
0xc0a5d410 <drv_data+252356>:   0xd54825ff      0x25ffc0a5      0xc0a5d540
     0xd52425ff
0xc0a5d420 <drv_data+252372>:   0x25ffc0a5      0xc0a5d4a4      0x00000000
     0x00000000
(gdb)

Here's everything I can think of to find out what's at that address:

(gdb) x/8i 0xc0a5d548
0xc0a5d548 <drv_data+252668>:   aam    0x7f
0xc0a5d54a <drv_data+252670>:   add    eax,0x0
0xc0a5d54f <drv_data+252675>:   add    BYTE PTR [eax],al
0xc0a5d551 <drv_data+252677>:   add    BYTE PTR [eax],al
0xc0a5d553 <drv_data+252679>:   add    BYTE PTR [eax],al
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Ritter | 3 Aug 2005 01:26
Picon
Favicon

Porting FreeBSD NDIS to NetBSD/nmb_fddirxindicate_func()

Hi, I'm trying to port the FreeBSD NDIS code to NetBSD as part of Google's
"Summer of Code" project (http://code.google.com/summerofcode.html).

I'm having a little problem right now, when the attach function calls
ndis_init_nic(), which calls the MiniportInitalize() function from the
binary Windows driver for my network card (I got this working on FreeBSD)
it blows up on the following instruction:

call   DWORD PTR [eax+380]

After playing around with the debugger a bit I'm quite certain that eax is
a pointer to the ndis_miniport_block, and 380 is the offset of the
nmb_fddirxindicate_func() field within it.  All there is at this address,
however is 0x0:

(gdb) x/8a $eax + 380
0xc15b2d7c:     0x0     0x0     0x0     0x0
0xc15b2d8c:     0xc0745955 <ndis_status_func>   0xc07459ad
<ndis_statusdone_func>       0x0     0xc0745a32 <ndis_getdone_func>

I'm assuming that this should have been initialized somewhere, but I can't
find any place in the code where nmb_fddirxindicate_func() is referenced. 
Maybe it is supposed to be initialized inside the binary Windows driver?

I also tried jumping past the offending instruction, and there appeared to
be more calls to uninitialized functions in the ndis_miniport_block().

Anyway, I just thought I'd check and see if you knew more about the
nmb_fddirxindicate_func() member of the ndis_miniport_block structure.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank van der Linden | 1 Aug 2005 21:33
Picon

Re: SoC: NDIS


>I think I may have finally ran into a problem with this.  So far I haven't
>had to make any modifications to the PE code (subr_pe.c), and I've been
>able to call into the binary Windows driver and it's been calling
>NdisXXX() functions just fine.  Right now I'm trying to get through the
>MiniportInitalize() function (inside the Windows binary).  It calls a
>bunch of the Ndis functions to set up the device, then it blows up after
>the following machine instruction:
>
>jmp ds:0xc0a5d548
>
>This is what happens when I try to step past it:
>
>8: x/i $pc 0xc0a5d410 : jmp ds:0xc0a5d548
>(gdb) si
>0x00057fd4 in ?? ()
>8: x/i $pc 0x57fd4: Cannot access memory at address 0x57fd4
>Disabling display 8 to avoid infinite recursion.
>(gdb)
>
>As you can see the program counter is getting set to an invalid memory
>address.  I'm thinking this might be a problem with how the segment
>registers are set up.
>  
>
Actually, the segment registers look normal for NetBSD purposes (ignore 
the upper bits of what gdb says they are).

I'm not quite sure what gdb disassembles as "jmp ds:XXXXXX". It might 
just be a plain pointer jump, with the pointer being at 0xc0a5d548. What
(Continue reading)

Permalink | Reply | 1 comment |
headers
Manuel Bouyer | 3 Aug 2005 11:15

Re: using usb HID under netBSD 2.0.2

On Mon, Aug 01, 2005 at 10:04:38AM +0100, lepingouin.tux wrote:
> [...]
> dmesg :
> 
> NetBSD 2.0.2 (GENERIC) #0: Wed Mar 23 08:53:42 UTC 2005
>    
> jmc <at> faith.netbsd.org:/home/builds/ab/netbsd-2-0-2-RELEASE/i386/200503220140Z-obj/home/builds/ab/netbsd-2-0-2-RELEASE/src/sys/arch/i386/compile/GENERIC
> total memory = 223 MB
> avail memory = 211 MB
> BIOS32 rev. 0 found at 0xfb3f0
> mainbus0 (root)
> cpu0 at mainbus0: (uniprocessor)
> cpu0: AMD Duron (686-class), 1303.05 MHz, id 0x671
> cpu0: features c3c3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR>
> cpu0: features c3c3fbff<PGE,MCA,CMOV,PAT,PSE36,MMXX,MMX>
> cpu0: features c3c3fbff<FXSR,SSE,3DNOW2,3DNOW>
> cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way
> cpu0: L2 cache 64 KB 64B/line 16-way
> cpu0: ITLB 16 4 KB entries fully associative, 8 4 MB entries fully 
> associative
> cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries 4-way
> cpu0: 8 page colors
> isa0 at mainbus0

There's something really wrong here, it doens't find any PCI bus (and so no
PCI devices). What motherboard is it ?

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank van der Linden | 3 Aug 2005 21:15
Picon

Re: using usb HID under netBSD 2.0.2

Ok, since no PCI buses show up, try compiling a kernel with the 
following in the config file:

acpi0 at mainbus0

options MPACPI
options MPACPI_SCANPCI

..and see if a PCI bus shows up then.

If you can't compile a kernel, I can compile one for you if you want to.

- Frank
Permalink | Reply | 0 comments |
headers
Julio M. Merino Vidal | 3 Aug 2005 22:06
Picon

tmpfs: Reclaiming vnodes

Hi all (and mentors),

The existing tmpfs code allocates new vnodes for each
access within the filesystem; e.g., the lookup operation gets a
new vnode for each match and returns it.  This hasn't caused
problems until now (despite it's plain wrong).

During the past days, I've been implementing the rmdir vnode
operation.  As this removes information from the file-system,
problems have started to pop up.  Basically, multiple vnodes
were pointing to the same tmpfs_node structure; when the
structure was freed, those vnodes were left with dangling
pointers in them, causing memory faults in future accesses.
So I have to change the code to use a single vnode for a
concrete file.

So far, I've got a fix that avoids crashes, but I doubt it's correct
(comparing it to other file-systems' code).  And even if it is,
I have several doubts that the manual pages (vnode(9) and
vnodeops(9)) do not solve.

First of all, I've changed the file-system specific node structure
(tmpfs_node) to keep a pointer to a vnode (let's call this
tn_vnode).  When creating the node, tn_vnode is initialized to
NULL, because there is no vnode associated to it yet.

Later on, when tmpfs needs to get a vnode for a specific
tmpfs_node, it checks if tn_vnode is NULL.  If it is, it gets a new
vnode (using getnewvnode), attaches it to the tmpfs_node and
uses it.  If it's not, it calls vget on tn_vnode and uses that.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alan Ritter | 4 Aug 2005 02:03
Picon
Favicon

Re: [Fwd: Re: Porting FreeBSD NDIS to NetBSD/nmb_fddirxindicate_func()]

Hi,

>> This is an excellent idea!  I just got started on it, now I just need to
>> go through, and print out each of the fields, I'm using a macro for this
>> of course but it's still tedious.  Here's what I've done to get it
>> started:
>>
>> bash-3.00$ ./test
>> sizeof(ndis_miniport_block) == 0x19c == 412
>> offset of nmb_signature: 0
>> offset of nmb_nextminiport: 4
>> offset of nmb_driverhandle: 8
>> offset of nmb_miniportadapterctx: 12
>
> According to a small program I just cooked up:
>
> [/sys/compat/ndis]:test{685}% ./a.out
> sizeof(nmb_status_block): 0x244 (580)
> nmb_status_func: 0x17c (380)
>
> So your structure size is definitely off.
>
> The program I wrote is:
>
> #include <sys/types.h>
> #include <sys/param.h>
> #include <sys/callout.h>
>
> #include <sys/kernel.h>
> #include <sys/module.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Studenmund | 4 Aug 2005 22:09
Picon

Re: tmpfs: Reclaiming vnodes

On Wed, Aug 03, 2005 at 10:06:53PM +0200, Julio M. Merino Vidal wrote:
> Hi all (and mentors),
> 
> The existing tmpfs code allocates new vnodes for each
> access within the filesystem; e.g., the lookup operation gets a
> new vnode for each match and returns it.  This hasn't caused
> problems until now (despite it's plain wrong).

Yeah, that's wrong.

> During the past days, I've been implementing the rmdir vnode
> operation.  As this removes information from the file-system,
> problems have started to pop up.  Basically, multiple vnodes
> were pointing to the same tmpfs_node structure; when the
> structure was freed, those vnodes were left with dangling
> pointers in them, causing memory faults in future accesses.
> So I have to change the code to use a single vnode for a
> concrete file.

Indeed.

> So far, I've got a fix that avoids crashes, but I doubt it's correct
> (comparing it to other file-systems' code).  And even if it is,
> I have several doubts that the manual pages (vnode(9) and
> vnodeops(9)) do not solve.
> 
> First of all, I've changed the file-system specific node structure
> (tmpfs_node) to keep a pointer to a vnode (let's call this
> tn_vnode).  When creating the node, tn_vnode is initialized to
> NULL, because there is no vnode associated to it yet.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Thorpe | 5 Aug 2005 06:33

Re: tmpfs: Reclaiming vnodes


On Aug 3, 2005, at 1:06 PM, Julio M. Merino Vidal wrote:

> Then, I have problems with the rmdir operation itself.  I first
> detach a_vp from its tmpfs_node by setting v_data and
> tn_node both to NULL.  Then I call vput over a_vp, as other
> file-systems do.  After this, I free the associated tmpfs_node
> given that no-one else is pointing to it.

But you'll note that other file systems don't free their v_data.   
That's because there is only one way that the VFS layer asks the file  
system to tear down the relationship.  That's the VOP_RECLAIM()  
path.  That is the only place where you should be tearing your  
tmpfs_node down.

> *But* a_vp is not really "released".  When I unmount the
> file-system, the kernel calls the fsync and reclaim operations
> over the value a_vp had (the vnode used during rmdir).  As
> this vnode has v_data set to NULL, any attempt to access the
> structure obviously fails and panics the system.

Right.  So don't do that in your rmdir routine... wait for the VFS  
layer to reclaim the vnode, then you should be OK.

-- thorpej
Permalink | Reply | 1 comment |

Gmane