Skip to Content.
Sympa Menu

freetds - Re: set textsize 1048576 fails

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: set textsize 1048576 fails
  • Date: Mon, 29 Oct 2001 19:01:25 -0500 (EST)


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 ;-)





Archive powered by MHonArc 2.6.24.

Top of Page