[LinuxBIOS] FILO with the USB

[Fridel Fainshtein]

Hello all,

It seams that the USB code was taken from the previous version of FILO
but never have been tested.

Some symptoms are
1)
malloc_diag: alloc: 4208 bytes (8 blocks), free: 61320 bytes (1 blocks)
malloc_check: sizes mismatch: 0xa1 vs 0x0 at 00132670
2)
dma_to_td: can not find td

Trying to debug it, I discovered the following piece of code:

void *allot2(size_t size, unsigned int alignment)
{
    void *addr;
    unsigned long addrval;
    addr=malloc(2*size);

addrval=(unsigned long)addr;
    addrval+=alignment+1; //  0x12345600 + 0xff + 1
    addrval&=~alignment;  //  0x12345700
    *(void * *)(addrval-sizeof(unsigned long))=addr;
    return (void *)addrval;
}

void forget2(void *mem)
{
    unsigned long addr=(unsigned long)mem;
    
    addr-=sizeof(unsigned long);
    free((void *)(*(unsigned long *)addr));
}

I have 2 questions:
if size = 8 and alignment=256, it writes outside malloc allocation, isn't it?
What was the meaning of the code?

Thanks

[Corey Osgood]

Fridel Fainshtein wrote:
> Hello all,
>
> It seams that the USB code was taken from the previous version of FILO
> but never have been tested.

Since noone else piped up, here's what I've figured out:
Older versions of FILO (<0.5) don't have any USB support. The original
author(s) of FILO's USB stack were from LinuxLabs. I don't know what the
story is, but it was probably written under contract for someone (in a
case where it did work), and they simply don't have the time to provide
support for it. I've heard that it was originally merged from Etherboot,
where it may have worked, but I can't confirm that. In any case, it
doesn't seem to have been really touched since the initial import to the
svn repository, according to the svn logs.
> Some symptoms are
>
> malloc_diag: alloc: 4208 bytes (8 blocks), free: 61320 bytes (1 blocks)
> malloc_check: sizes mismatch: 0xa1 vs 0x0 at 00132670
> 2)
> dma_to_td: can not find td

Is this using an OHCI controller? I've tried several times with UHCI and
seen a different error:

malloc_diag: alloc: xxxx bytes ([x] blocks), free: xxxx bytes (2 blocks)
init_framelist: frame_list is at 13[n]000
dump_link: frame_list_link: addr: 001233[n+1]0
dump_link: frame_list_link:  raw addr: 1bfd40[n*2]0
dump_link: frame_list_link: terminate: 0
dump_link: frame_list_link: queue: 1
dump_link: frame_list_link: depth: 0
(repeated half a dozen or so times)
Out of heap space
> Trying to debug it, I discovered the following piece of code:
>
> void *allot2(size_t size, unsigned int alignment)
> {
>    void *addr;
>    unsigned long addrval;
>    addr=malloc(2*size);
>
> addrval=(unsigned long)addr;
>    addrval+=alignment+1; //  0x12345600 + 0xff + 1
>    addrval&=~alignment;  //  0x12345700
>    *(void * *)(addrval-sizeof(unsigned long))=addr;
>    return (void *)addrval;
> }
>
> void forget2(void *mem)
> {
>    unsigned long addr=(unsigned long)mem;
>
> addr-=sizeof(unsigned long);
>    free((void *)(*(unsigned long *)addr));
> }
>
> I have 2 questions:
> if size = 8 and alignment=256, it writes outside malloc allocation, isn't it?
> What was the meaning of the code?
>
> Thanks

No idea. This does sound like something worth taking a look at, you
might want to investigate how Etherboot does malloc/allot and also see
if USB really does work there.

Good luck!
Corey

[Stefan Reinauer]

* Fridel Fainshtein  [071114 20:03]:
> Hello all,
>
> It seams that the USB code was taken from the previous version of FILO
> but never have been tested.
>
> Some symptoms are
>
> malloc_diag: alloc: 4208 bytes (8 blocks), free: 61320 bytes (1 blocks)
> malloc_check: sizes mismatch: 0xa1 vs 0x0 at 00132670
> 2)
> dma_to_td: can not find td
>
> Trying to debug it, I discovered the following piece of code:
>
> void *allot2(size_t size, unsigned int alignment)
> {
>    void *addr;
>    unsigned long addrval;
>    addr=malloc(2*size);
>
> addrval=(unsigned long)addr;
>    addrval+=alignment+1; //  0x12345600 + 0xff + 1
>    addrval&=~alignment;  //  0x12345700
>    *(void * *)(addrval-sizeof(unsigned long))=addr;
>    return (void *)addrval;
> }
>
> void forget2(void *mem)
> {
>    unsigned long addr=(unsigned long)mem;
>
> addr-=sizeof(unsigned long);
>    free((void *)(*(unsigned long *)addr));
> }
>
> I have 2 questions:
> if size = 8 and alignment=256, it writes outside malloc allocation, isn't it?

Oh yes! I added those two functions as a quick hack to get things
compile. I think it never worked with them. Since the rest of the code
is very similar to filo+etherboot this is likely to be the problem.

Does the code try to allocate blocks with size = 8 and alignment=256?
> What was the meaning of the code?

FILO had no memory alloc function that would allow you to give an
alignment. That's the only purpose they're good for.

If you can come up with a better/working solution, we'll happily
integrate it!

Stefan