syllable-kernel — The list is for discussion of Kernel issues by developers

Re: [Syllable-kernel] Syllable-kernel Digest, Vol 2, Issue 2

[Arno K. <arn...@ya...>]

Nico van Huis schrieb:
> I don`t understand the following lines, so i can`t solve the problem,
> please help!!
>
> 325 static void tg3_write_indirect_reg32(struct tg3 *tp, u32 off, u32 val)
> 326 {
> 327  //PCI_bus_s *psBus = g_psBus;
> 328  PCI_bus_s* psBus = get_busmanager( PCI_BUS_NAME, PCI_BUS_VERSION ); 
> 329  if( psBus == NULL ) {
> 330      return( NULL );
> 331     }
> 332  
> 333  unsigned long flags;
> 334  
> 335  spin_lock_irqsave(&tp->indirect_lock, flags);
> 336  psBus->write_pci_config(
> 337   &(tp)->pdev->nBus, 
> 338   &tp->pdev->nDevice, 
> 339   &tp->pdev->nFunction, 
> 340   TG3PCI_REG_BASE_ADDR, 
> 341   sizeof(off), 
> 342   (uint32)off);
> 343  //pci_write_config_dword(tp->pdev, TG3PCI_REG_BASE_ADDR, off);
> 344  psBus->write_pci_config(
> 345   &tp->pdev->nBus, 
> 346   &tp->pdev->nDevice, 
> 347   &tp->pdev->nFunction, 
> 348   TG3PCI_REG_DATA, 
> 349   val);
> 350  //pci_write_config_dword(tp->pdev, TG3PCI_REG_DATA, val);
> 351  spin_unlock_irqrestore(&tp->indirect_lock, flags);
> 352 }
>   
Ok, the first thing you should do is to define the busmanager pointer as 
a global variable because calling get_busmanager() everytime you write a 
register is not very efficient. So add something like this:

static PCI_bus_s* g_psBus;

To get access to the busmanager (see atheos/pci.h for all provided 
functions) you need to call get_busmanager(). So put this:

g_psBus = get_busmanager( PCI_BUS_NAME, PCI_BUS_VERSION );

into the device_init() function of your driver (if you have already 
added it). The linux pci device structure is not mapped to the syllable 
one and so you need to
change the type of the pdev member to PCI_Info_s. Now if you reenable 
the line:

PCI_bus_s *psBus = g_psBus;


you do not even have to replace the linux pci functions with the 
syllable ones.

P.S.: The best way is to look at the other syllable network drivers and 
see how the driver interface and the access to pci devices works.

Arno


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Syllable-kernel] Syllable-kernel Digest, Vol 2, Issue 2

[Nico v. H. <va...@va...>]

I don`t understand the following lines, so i can`t solve the problem,
please help!!

325 static void tg3_write_indirect_reg32(struct tg3 *tp, u32 off, u32 val)
326 {
327  //PCI_bus_s *psBus = g_psBus;
328  PCI_bus_s* psBus = get_busmanager( PCI_BUS_NAME, PCI_BUS_VERSION ); 
329  if( psBus == NULL ) {
330      return( NULL );
331     }
332  
333  unsigned long flags;
334  
335  spin_lock_irqsave(&tp->indirect_lock, flags);
336  psBus->write_pci_config(
337   &(tp)->pdev->nBus, 
338   &tp->pdev->nDevice, 
339   &tp->pdev->nFunction, 
340   TG3PCI_REG_BASE_ADDR, 
341   sizeof(off), 
342   (uint32)off);
343  //pci_write_config_dword(tp->pdev, TG3PCI_REG_BASE_ADDR, off);
344  psBus->write_pci_config(
345   &tp->pdev->nBus, 
346   &tp->pdev->nDevice, 
347   &tp->pdev->nFunction, 
348   TG3PCI_REG_DATA, 
349   val);
350  //pci_write_config_dword(tp->pdev, TG3PCI_REG_DATA, val);
351  spin_unlock_irqrestore(&tp->indirect_lock, flags);
352 }

bash-2.03$ make
cc -kernel -fno-PIC -c tg3.c -o objs/tg3.o
tg3.c:218: warning: parameter names (without types) in function declaration
tg3.c:218: warning: data definition has no type or storage class
tg3.c: In function `tg3_write_indirect_reg32':
tg3.c:330: warning: `return' with a value, in function returning void
tg3.c:337: error: dereferencing pointer to incomplete type
tg3.c:338: error: dereferencing pointer to incomplete type
tg3.c:339: error: dereferencing pointer to incomplete type
tg3.c:345: error: dereferencing pointer to incomplete type
tg3.c:346: error: dereferencing pointer to incomplete type
tg3.c:347: error: dereferencing pointer to incomplete type
tg3.c:349: error: too few arguments to function
tg3.c:352:2: warning: no newline at end of file
make: *** [objs/tg3.o] Error 1

I really want to understand what the psBus does and their functions...
can anyone explain and help to solve this??

Re: [Syllable-kernel] Network driver (tg3)

[Kristian V. D. V. <va...@li...>]

On Sunday 15 October 2006 15:19, Nico van Huis wrote:
> I get an erroron the following lines:
>
> 223:#define TG3PCI_REG_BASE_ADDR            0x00000078
> 224:#define TG3PCI_REG_DATA                 0x00000080
> 225:static void tg3_write_indirect_reg32(struct tg3 *tp, u32 off, u32 val)
> 226:{
> 227: unsigned long flags;
> 228:
> 229: spin_lock_irqsave(&tp->indirect_lock, flags);
> 330: pci_write_config_dword(tp->pdev, TG3PCI_REG_BASE_ADDR, off);
> 331: pci_write_config_dword(tp->pdev, TG3PCI_REG_DATA, val);
> 332: spin_unlock_irqrestore(&tp->indirect_lock, flags);
> 333:}
>
> It says:
>
> bash-2.03$ make
> cc -kernel -fno-PIC -c tg3.c -o objs/tg3.o
> tg3.c:218: warning: parameter names (without types) in function declarati=
on
> tg3.c:218: warning: data definition has no type or storage class
> tg3.c: In function `tg3_write_indirect_reg32':
> tg3.c:330: error: `psBus' undeclared (first use in this function)
> tg3.c:330: error: (Each undeclared identifier is reported only once
> tg3.c:330: error: for each function it appears in.)
> tg3.c:330: error: dereferencing pointer to incomplete type
> tg3.c:330: error: dereferencing pointer to incomplete type
> tg3.c:330: error: dereferencing pointer to incomplete type
> tg3.c:331: error: dereferencing pointer to incomplete type
> tg3.c:331: error: dereferencing pointer to incomplete type
> tg3.c:331: error: dereferencing pointer to incomplete type
> tg3.c:333:2: warning: no newline at end of file
> make: *** [objs/tg3.o] Error 1
>
> As you can read it says 'psBus' undeclared... well i think it is but it is
> also never been used in these lines and nowhere else in the code.

=46rom linux_comp.h:

#define pci_write_config_byte(dev, address, val) \
	psBus->write_pci_config((dev)->nBus, (dev)->nDevice, (dev)->nFunction,=20
address, sizeof(val), (uint32)val)

> Does anyone do know where this error possibly come from?

You probable have a "g_psBus" that is global to the entire driver.  The bes=
t=20
way to handle this is to change the Linux pci_write_config_byte() to a=20
Syllable psBus->write_pci_config() yourself in the code:

psBus->write_pci_config(tp->pdev->nBus, tp->pdev->nDevice,=20
tp->pdev->nFunction, TG3PCI_REG_BASE_ADDR, sizeof(off), (uint32)off);

Or failing that, ensure any function that uses macros has a local psBus:

PCI_bus_s *psBus =3D g_psBus;

at the top of the function.

=2D-=20
Vanders
http://www.syllable.org
http://www.liqwyd.com

Re: [Syllable-kernel] Network driver (tg3)

[Wang Y. <ypw...@gm...>]

Hi, Nico

I don't have experience in Device Driver on Syllable. After I google
"psBus", I found the following link:

http://www.other-space.com/sub/?section=System_Programming&tutorial=Device_Drivers

Does it possible that it needs some header file to include when porting on
Syllable?

Hope that can help.

Cheers,
Andy


On 10/15/06, Nico van Huis <va...@va...> wrote:
>
>  I get an erroron the following lines:
>
> 223:#define TG3PCI_REG_BASE_ADDR            0x00000078
> 224:#define TG3PCI_REG_DATA                 0x00000080
> 225:static void tg3_write_indirect_reg32(struct tg3 *tp, u32 off, u32 val)
> 226:{
> 227: unsigned long flags;
> 228:
> 229: spin_lock_irqsave(&tp->indirect_lock, flags);
> 330: pci_write_config_dword(tp->pdev, TG3PCI_REG_BASE_ADDR, off);
> 331: pci_write_config_dword(tp->pdev, TG3PCI_REG_DATA, val);
> 332: spin_unlock_irqrestore(&tp->indirect_lock, flags);
> 333:}
>
> It says:
>
> bash-2.03$ make
> cc -kernel -fno-PIC -c tg3.c -o objs/tg3.o
> tg3.c:218: warning: parameter names (without types) in function
> declaration
> tg3.c:218: warning: data definition has no type or storage class
> tg3.c: In function `tg3_write_indirect_reg32':
> tg3.c:330: error: `psBus' undeclared (first use in this function)
> tg3.c:330: error: (Each undeclared identifier is reported only once
> tg3.c:330: error: for each function it appears in.)
> tg3.c:330: error: dereferencing pointer to incomplete type
> tg3.c:330: error: dereferencing pointer to incomplete type
> tg3.c:330: error: dereferencing pointer to incomplete type
> tg3.c:331: error: dereferencing pointer to incomplete type
> tg3.c:331: error: dereferencing pointer to incomplete type
> tg3.c:331: error: dereferencing pointer to incomplete type
> tg3.c:333:2: warning: no newline at end of file
> make: *** [objs/tg3.o] Error 1
>
> As you can read it says 'psBus' undeclared... well i think it is but it is
> also never been used in these lines
> and nowhere else in the code.
>
> Does anyone do know where this error possibly come from?
>
> Nico
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Syllable-kernel mailing list
> Syl...@li...
> https://lists.sourceforge.net/lists/listinfo/syllable-kernel
>
>
>

[Syllable-kernel] Network driver (tg3)

[Nico v. H. <va...@va...>]

I get an erroron the following lines:

223:#define TG3PCI_REG_BASE_ADDR            0x00000078
224:#define TG3PCI_REG_DATA                 0x00000080
225:static void tg3_write_indirect_reg32(struct tg3 *tp, u32 off, u32 val)
226:{
227: unsigned long flags;
228:
229: spin_lock_irqsave(&tp->indirect_lock, flags);
330: pci_write_config_dword(tp->pdev, TG3PCI_REG_BASE_ADDR, off);
331: pci_write_config_dword(tp->pdev, TG3PCI_REG_DATA, val);
332: spin_unlock_irqrestore(&tp->indirect_lock, flags);
333:}

It says:

bash-2.03$ make
cc -kernel -fno-PIC -c tg3.c -o objs/tg3.o
tg3.c:218: warning: parameter names (without types) in function declaration
tg3.c:218: warning: data definition has no type or storage class
tg3.c: In function `tg3_write_indirect_reg32':
tg3.c:330: error: `psBus' undeclared (first use in this function)
tg3.c:330: error: (Each undeclared identifier is reported only once
tg3.c:330: error: for each function it appears in.)
tg3.c:330: error: dereferencing pointer to incomplete type
tg3.c:330: error: dereferencing pointer to incomplete type
tg3.c:330: error: dereferencing pointer to incomplete type
tg3.c:331: error: dereferencing pointer to incomplete type
tg3.c:331: error: dereferencing pointer to incomplete type
tg3.c:331: error: dereferencing pointer to incomplete type
tg3.c:333:2: warning: no newline at end of file
make: *** [objs/tg3.o] Error 1

As you can read it says 'psBus' undeclared... well i think it is but it is also never been used in these lines
and nowhere else in the code.

Does anyone do know where this error possibly come from?

Nico

[Syllable-kernel] Network driver (tg3)

[Nico v. H. <va...@va...>]

Hello,

I`m new to kernel and driver programming, but i`d like to participate!
I`ve installed syllable on my laptop, but syllable didn`t found my network card.

After a little research i found out that the tg3 driver wasn`t ported.
So i downloaded the linux drivers and tried to port it myself.
after copy, paste and adjust the first few lines and compiled them i got a lot of errors:


static struct pci_device_id tg3_pci_tbl[] = {
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5700, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5701, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5703, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5704, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702FE, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705_2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705M_2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702X, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5703X, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5704S, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5702A3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5703A3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5782, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5788, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5789, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5901, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5901_2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5704S_2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5705F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5720, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5721, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5750, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5750M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5751F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5752, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5752M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5753F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5754, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5754M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5755, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5755M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5786, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5787M, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5714, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5714S, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5715, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5715S, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5780, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5780S, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_TIGON3_5781, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_9DXX, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_9MXX, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC1000, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC1001, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC1003, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_ALTIMA, PCI_DEVICE_ID_ALTIMA_AC9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { PCI_VENDOR_ID_APPLE, PCI_DEVICE_ID_APPLE_TIGON3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
 { 0, }
};

ok this is a struct with a few constants, but didn`t found their declaration in the linux driver code nor in the
linux kernel code, can anyone help me with this?? searched the internet... couldn`t find anything....

and i always get an error on "u32", is this an invalid integer or something??

please help, i may sound like a noob, cause i am! but you all started somewhere too :P

[Syllable-kernel] =?iso-2022-jp?b?GyRCJCo0aiQkJDckXiQ5GyhC?=

[<as...@ya...>]

誰かと一緒に居たいです。
http://369com.com/shio/

Re: [Syllable-kernel] PCMCIA / CardBus

[Kristian V. D. V. <va...@li...>]

On Sun, 26 Mar 2006 10:48:46 +0000, James Pickering <syl...@ja...> wrote:
> Just a quick question. Is anybody working on a bus manager for PCMCIA/Cardbus?
> 
> Also while I'm doing this mail. WiFi, Has their been any progress on deciding 
> which stack (Am I right here?) is going to be used in Syllable?

I'd send this to syllable-developer; not many people are active on this list.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com
 

[Syllable-kernel] PCMCIA / CardBus

[James P. <syl...@ja...>]

Hi,

Just a quick question. Is anybody working on a bus manager for PCMCIA/Cardbus?

Also while I'm doing this mail. WiFi, Has their been any progress on deciding 
which stack (Am I right here?) is going to be used in Syllable?

Tar

Jim

Re: [Syllable-kernel] Small kernel TLD patch for get_tld_addr()

[Kristian V. D. V. <va...@li...>]

On Sunday 01 January 2006 22:02, Daniel Gryniewicz wrote:
> On Sun, 2006-01-01 at 23:03 +0000, Kristian Van Der Vliet wrote:
>> I just want to run this past you all quickly before I go ahead and check
>> this in.
>
> Looks straight forward to me.  Anything that reduces the number of
> syscalls is a very good thing.

In addition I can save the six or so calls to alloc_tld() at every execve() & 
spawn_thread() by using the first 1k of thread data.  At the moment only the 
bottom 24 bytes are used (PID, TID, ERRNO, ERRNO_ADDR, BASE), so if we 
reserve 512-1024 for libc specific TLD data there'll be no need to allocate 
them out of the user TLD space.

Without adding lazy bindings to the ELF loader or support for SYSENTER/SYSCALL 
instead of 0x80 syscalls, I can't do much more to speed things up.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

Re: [Syllable-kernel] Small kernel TLD patch for get_tld_addr()

[Daniel G. <da...@fp...>]

On Sun, 2006-01-01 at 23:03 +0000, Kristian Van Der Vliet wrote:
> I just want to run this past you all quickly before I go ahead and check this in.
> 
> The patch adds an additional pre-defined TLD, TLD_BASE, which gives us
> the address of the thread data E.g. the address of the first TLD.  This allows
> me to re-write get_tld_addr() to calculate the address of any TLD without
> the need for a syscall.  This neatly removes a whole heap of regular syscalls
> to get_tld_addr()
> 
> Any objections?  Note that this doesn't make any difference until I release
> the matching Glibc, but it will be required at that point.
> 

Looks straight forward to me.  Anything that reduces the number of
syscalls is a very good thing.

Daniel

[Syllable-kernel] Small kernel TLD patch for get_tld_addr()

[Kristian V. D. V. <va...@li...>]

I just want to run this past you all quickly before I go ahead and check this in.

The patch adds an additional pre-defined TLD, TLD_BASE, which gives us
the address of the thread data E.g. the address of the first TLD.  This allows
me to re-write get_tld_addr() to calculate the address of any TLD without
the need for a syscall.  This neatly removes a whole heap of regular syscalls
to get_tld_addr()

Any objections?  Note that this doesn't make any difference until I release
the matching Glibc, but it will be required at that point.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

Re: [Syllable-kernel] ftruncate() for AFS

[Kristian V. D. V. <va...@li...>]

On Wednesday 28 December 2005 02:46, Daniel Gryniewicz wrote:
> Here's an updated ftruncate() for AFS

Cool, thanks Daniel.  I'll give it a test next week when I'm back at a 
different machine; some real world testing with something I know relies on 
ftruncate() (Samba) will be nice.

I'll also have a libc that calls fsync() for you later today or tommorow.

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

[Syllable-kernel] ftruncate() for AFS

[Daniel G. <da...@fp...>]

Hi, all

Here's an updated ftruncate() for AFS>  It works well (in that it
truncates/expands to the right size, zero fills, and doesn't destroy my
filesystem) in my tests.  I'm going to write a more extensive stress
test than my three random truncate loops soon, but I think it stable
enough to be posted.

Daniel

[Syllable-kernel] crazy compiler error messages

[<dem...@ne...>]

Does anybody know what causes the 'stray \194' or 'stray \160' errors in gcc?  These errors are coming from gcc version 3.4.3.  They are found in lines of code that correspond to a structure definition that I created.  Any help would be greatly apprieciated!:)

-Dee

__________________________________________________________________
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

Re: [Syllable-kernel] Porting Drivers

[Arno K. <arn...@ya...>]

Steven Picken schrieb:

> I had thought I saw a mailing list topic about this, but apparently not.
>
> I've finally got myself a new machine to run Syllable again, but it's 
> using a Marvell Yukon chipset, which isn't supported yet in Syllable.
> Is there a set of pointers that you could give me about porting 
> drivers over from Linux, and I'll take a shot at it.
>
> --Steven

I think all syllable network drivers are ports of the linux drivers and 
so you should first look there. Most of them define the linux net_device 
structure in their source file. Many also use a file called 
"linuxcomp.h" which wraps some of the linux commands to syllable. The 
most complete one seems to be in the file in the dp83815 directory. Some 
of the functions can´t be wrapped correctly and you have to change the 
code manually, e.g. the timer and area functions. If you have more 
questions just post here again.

Arno

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: [Syllable-kernel] Porting Drivers

[Kristian V. D. V. <va...@li...>]

On Friday 21 October 2005 13:25, Steven Picken wrote:
> I've finally got myself a new machine to run Syllable again, but it's
> using a Marvell Yukon chipset, which isn't supported yet in Syllable.
> Is there a set of pointers that you could give me about porting drivers
> over from Linux, and I'll take a shot at it.

The only real reference is the current ports, so you'll have to read some of 
them to get an idea of what needs to be changed.

Most of the code will port without changes, although there are some 
modifications you'll need to make, including but not limited to:

o Semaphore & Spinlock types and initialisation
o skb management methods are different; there is no skb_put() function, but
    there is a macro in most lincomp.h headers that emulate it.
o Slight differences in the IRQ handlers, and no top-half/bottom-half
    interupts.
o Syllable will require it's own hardware detection routines; PCI access &
    device management is different in Syllable (Although the actual PCI
    read/write functions themselves are very similiar)

A lot of the differences are hidden via. the header lincomp.h, which provides 
macros and wrappers for Linux functions that don't exist on Syllable.

If you have any questions you can ask here, but the syllable-developer mailing 
lists may get you more/quicker responses.

Good luck!

-- 
Vanders
http://www.syllable.org
http://www.liqwyd.com

[Syllable-kernel] Porting Drivers

[Steven P. <cod...@bi...>]

I had thought I saw a mailing list topic about this, but apparently not.

I've finally got myself a new machine to run Syllable again, but it's 
using a Marvell Yukon chipset, which isn't supported yet in Syllable.
Is there a set of pointers that you could give me about porting drivers 
over from Linux, and I'll take a shot at it.

--Steven

Re: [Syllable-kernel] Third party graphics drivers

[Daniel G. <da...@fp...>]

On Sat, 2005-10-15 at 00:41 +0200, c....@fr... wrote:
> hello all,
> 
> I recently read a whole lot of MSDN documentation about the LDDM
> infrastructure. The new Windows graphics vista driver model.
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Display_d/hh/Display_d/DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f06eb8.xml.asp
> 
> And what made me think we could have support for it in other OSes.
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Display_d/hh/Display_d/DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f06eb8.xml.asp
> 
> It seem to me that having the most important parts of the driver
> being in user mode would really help to use it on other systems.
> 
> with a PE binary loader and with some kernel support
> maybe it would be possible to use LDDM drivers in syllable.
> 
> >From what I read, the user mode driver would create the
> command buffer that would need to be uploaded to the
> GPU and the kernel module would need to schedule GPU
> access handle memory of the GPU and send the command
> buffer to it.
> 
> sorry if it sound crazy...

Well, if the driver interface is well defined enough (and I haven't read
it so I don't know), then it could be done.  ndiswrapper allows windows
network drivers to be used on Linux, and it's possible because of the
well defined NDIS API.  So, it's potentially not crazy, but it depends
on how the drivers are written and used.

Daniel

[Syllable-kernel] Third party graphics drivers

[<c....@fr...>]

hello all,

I recently read a whole lot of MSDN documentation about the LDDM
infrastructure. The new Windows graphics vista driver model.

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/Displa=
y_d/hh/Display_d/DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f=
06eb8.xml.asp

And what made me think we could have support for it in other OSes.

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/Displa=
y_d/hh/Display_d/DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f=
06eb8.xml.asp

It seem to me that having the most important parts of the driver
being in user mode would really help to use it on other systems.

with a PE binary loader and with some kernel support
maybe it would be possible to use LDDM drivers in syllable.

From what I read, the user mode driver would create the
command buffer that would need to be uploaded to the
GPU and the kernel module would need to schedule GPU
access handle memory of the GPU and send the command
buffer to it.

sorry if it sound crazy...

Re: [Syllable-kernel] sis900 driver

[Arno K. <arn...@ya...>]

Kaj de Vos schrieb:

>>If you have a setting like "plug & play os" in your bios then try to 
>>disable it. If this doesn´t help then we need the name of the network 
>>chip because the sis900 supports different chips.
>>
>>Arno
>>    
>>
>
>Richard already tried that; I pointed him here after he did. :-) Where 
>could he find the chip information in Syllable?
>
>Kaj
>
>  
>
Ok, there seems to be a small difference when reading the mac address 
between the syllable and the linux driver which _could_ cause this 
problem. I have changed this and uploaded the updated driver here:

http://www.liqwyd.com/arno/sis900.zip

Arno

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

Re: [Syllable-kernel] sis900 driver

[Kaj de V. <syl...@fr...>]

> Richard schrieb:
>=20
> >Hi all,
> >
> >I have some problems with the sis900 driver.
> >My network device is listed in 'Syllable Mananger', but it isn't in=20
> >'Preferences->Network'. When I look in /var/log/knerl I find these=20
lines:
> >=20
> >
> >>sis900=5Fprobe() found NIC
> >>sis900.c: v1.06.12  03/09/2004
> >>sis900: Error EERPOM read ffff
> >>=20
> >>
> >I hope you could help me out!
> >=20
> >
> If you have a setting like "plug & play os" in your bios then try to=20
> disable it. If this doesn=B4t help then we need the name of the network=20
> chip because the sis900 supports different chips.
>=20
> Arno

Richard already tried that; I pointed him here after he did. :-) Where=20
could he find the chip information in Syllable?

Kaj

Re: [Syllable-kernel] sis900 driver

[Arno K. <arn...@ya...>]

Richard schrieb:

>Hi all,
>
>I have some problems with the sis900 driver.
>My network device is listed in 'Syllable Mananger', but it isn't in 
>'Preferences->Network'. When I look in /var/log/knerl I find these lines:
>  
>
>>sis900_probe() found NIC
>>sis900.c: v1.06.12  03/09/2004
>>sis900: Error EERPOM read ffff
>>    
>>
>I hope you could help me out!
>  
>
If you have a setting like "plug & play os" in your bios then try to 
disable it. If this doesn´t help then we need the name of the network 
chip because the sis900 supports different chips.

Arno

	

	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

[Syllable-kernel] sis900 driver

[Richard <ric...@gm...>]

Hi all,

I have some problems with the sis900 driver.
My network device is listed in 'Syllable Mananger', but it isn't in 
'Preferences->Network'. When I look in /var/log/knerl I find these lines:
> sis900_probe() found NIC
> sis900.c: v1.06.12  03/09/2004
> sis900: Error EERPOM read ffff
I hope you could help me out!

- Richard

[Syllable-kernel] SMP and memory ordering consequences

[Jake H. <jak...@gm...>]

While reading _Solaris Internals: Core Kernel Components_ and stepping
through Sun's implementation of mutexes, I learned something about
memory barriers (fences) and why exactly we might need to use them to
fix at least some of our SMP bugs.  Since I'm busy with other projects
this week and don't have an SMP machine here to test on, I'll write up
what I've found, in lieu of actually poking around the kernel myself.=20
:-)

The relevant sections in the Intel IA-32 software developer's manual
Volume 3 are 7.2 (memory ordering) and 7.4 (serializing instructions),
but they don't explain much other than to state that in all current
Intel processors, loads and stores are executed in order with respect
to each other.  The following page, while written for Java VM
implementors, has a lot more useful detail, and covers all the popular
RISC CPU's in addition to x86:

http://gee.cs.oswego.edu/dl/jmm/cookbook.html

The important thing to note is the "StoreLoad" barrier type, which
flushes out all pending writes to memory before continuing.  Without
doing this, if we write to a memory location, then later read from the
same location, even if the variable was declared volatile, we might
get the processor's cached copy of the data, even if another processor
has written to that location in the meantime.  While the individual
CPU's in an SMP configuration keep their caches up-to-date through bus
snooping, this doesn't apply to data that is still in the processor's
write buffer and hasn't been pushed out to the cache yet.

"StoreLoad" is the only type of barrier required on current x86
systems (excluding AMD64), and the Pentium 4 and amd64 have a special
instruction for it, "mfence", but the portable way to do a StoreLoad
barrier on x86 is with a lock-prefixed memory access instruction, for
example the do-nothing "lock; xorl $0, (%esp)".

I don't know if this type of memory barrier is necessary to fix any of
the bugs that have been seen, but it's definitely a good thing to know
about.  BTW, the Linux macros for this type of memory barrier on x86
are mb(), rmb(), smp_mb(), and smp_rmb(), defined in
"include/asm-i386/system.h".  Linux also has a generic barrier() macro
defined in "include/linux/kernel.h" as '__asm__ __volatile__("": :
:"memory")', which is used to tell the compiler that memory contents
may have changed.

--
Jake