FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Tue, 30 Oct 2001, James Cameron wrote:

> Is there some test I can make to help trace this problem further?
>
> For instance, I'd love to write a little C program that interfaces to
> the TDS layer directly.  I could exclude PHP and Apache from the
> problem.  Is there a good example in CVS to start with?  Making the
> calls seems easy from the TDS unittests; it's processing the returned
> data which looks hard.
>
you can call tds_convert() to handle the returned data...I was going to
put together a libtds guide someday...maybe i will actually get to it.

can you generate a TDSDUMP trace log?

> Brian Bruns wrote:
> > [...] the RH 7.2 upgrade crapped out on my dev box, and I'm having
> > trouble getting the onboard sis900 network card going. (I had to do some
> > convoluted thing last time, and i forget what it was now).  Anyway, I'll
> > see what's up.
>
> In the interests of encouraging you ...
>
> - there should be an sis900 module in /lib/modules
>   find /lib/modules/`uname -r` -name sis900\*

> - at a guess, 'modprobe sis900' might make it work
>
> - at a guess, 'modprobe sis900' might make it work
>
Yes, however loading it complains about resource or device busy and says
to check the io and irq ports...no much help ;-) card is there lspci sees
it, just no go.  I slapped in an old realtek card temporarily and I'm up
and running again...Seems to be a PnP thing, as last time i think i had to
configure the sis900 with the realtek in and then remove the realtek card.

More hassle than it's worth. integrated peripherals....gotta love 'em.

> - editing /etc/conf.modules or /etc/modules.conf (can't remember which)
>   and adding an 'alias eth0 sis900' seems to be the thing to do
>
> - searched the kernel source for 2.4.9 and found plenty of references,
>   find . -type f -exec grep -i "sis900" {} /dev/null \;|more
>   Documentation/Configure.help
>   Documentation/networking/sis900.txt
>   drivers/net/sis900.c
>   drivers/net/sis900.h
>   drivers/pci/pci.ids
>
> - these matches scare me ... spelling errors ;-)
>   drivers/net/sis900.h:enum sis900_tx_buffer_status {
>   drivers/net/sis900.h:enum sis900_rx_bufer_status {
>
> - then I saw this in the documentation and giggled ... defects do
>   congregate in code, as it is the nature of coding that Bad Days
> generate
>   Bad Code.
>
>    "2. A bug is hidden somewhere in the receive buffer management code,
>        the bug causes NULL pointer reference in the kernel. This fault
> is
>        caught before bad things happen and reported with the message:
>        eth0: NULL pointer encountered in Rx ring, skipping which can be
>        viewed with dmesg or cat /var/log/message."

Maybe an upgraded kernal would help...however that's what started this
mess ;-)