Linux-Development-Sys Digest #616, Volume #8      Fri, 6 Apr 01 04:13:12 EDT

Contents:
  Low level serial driver not getting ioctl() (Grant Edwards)
  Re: Low level serial driver not getting ioctl() (Grant Edwards)
  Re: Low level serial driver not getting ioctl() (Grant Edwards)
  Re: Win Modems (Bill Unruh)
  Re: Kernel Panic in Network Interface
  Re: Kernel Panic in Network Interface (bill davidsen)
  RE: usleep() is unreliable when sleeping for less then 10000 micro 
([EMAIL PROTECTED])
  2.4.3 and initrd problem - fixed (bill davidsen)
  Re: Embedded Linux Device
  Re: Embedded Linux development? ("Joseph A. Knapka")
  How to control time irq ("tlin")
  Re: Zombies and daemons (Josef Moellers)
  Re: 2.4 kernels ("Lee Ho")
  Re: usleep() is unreliable when sleeping for less then 10000 micro (Pasztor Szilard)
  Re: Kernel Routing Question (afausti)
  Re: Zombies and daemons ("Brian Bisaillon")
  Re: 2.2.19 ( and older ) bug with Via KT133 ( dunno 'bout KT133A, eh? ) ("Brian 
Bisaillon")
  Re: kernel panic, killing interrupt handler ("Brian Bisaillon")
  Re: mysql or postgresql? which is better? ("Brian Bisaillon")
  Re: mysql or postgresql? which is better? ("Brian Bisaillon")
  Re: How to setup VPN in linux? ("Brian Bisaillon")

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Low level serial driver not getting ioctl()
Date: Thu, 05 Apr 2001 21:22:45 GMT

I've run into a problem when testing a serial driver I'm
maintaining: The mid-level serial driver isn't passing on some
of the ioctl() calls to my driver.

If an application calls tcgetattr/tcsetattr to enable/disable
XON/XOFF flow control, my driver never gets called.  If the app
changes something else (e.g. baud rate) at the same time, _then_
my driver gets called, and everything works right.

How do I get the mid-level serial driver to notify me of all
setattr() calls?

-- 
Grant Edwards                   grante             Yow!  My TOYOTA is built
                                  at               like a... BAGEL with CREAM
                               visi.com            CHEESE!!

------------------------------

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Low level serial driver not getting ioctl()
Date: Thu, 05 Apr 2001 21:28:20 GMT

In article <Fm5z6.11086$[EMAIL PROTECTED]>, Grant Edwards wrote:

>I've run into a problem when testing a serial driver I'm
>maintaining: The mid-level serial driver isn't passing on some
>of the ioctl() calls to my driver.
>
>If an application calls tcgetattr/tcsetattr to enable/disable
>XON/XOFF flow control, my driver never gets called.  If the app
>changes something else (e.g. baud rate) at the same time, _then_
>my driver gets called, and everything works right.
>
>How do I get the mid-level serial driver to notify me of all
>setattr() calls?

I should have added a pre-emptive reply to the ever-popular
c.o.l.* "you don't need to be able to do that" answer.  :)

My serial hardware has 4K Rx/Tx FIFOs and handles processing of
received Xon/Xoff characters in hardware.  I can't let the
middle level handle it because the large Rx FIFO means that
4000 byte-times could go by between the receipt of an Xoff and
the transmitter being halted.

I really do need my driver to be notified when the user changes
the state of the IXON or IXOFF flags so that I can configure
hardware appropriately.

-- 
Grant Edwards                   grante             Yow!  I will establish
                                  at               the first SHOPPING MALL in
                               visi.com            NUTLEY, New Jersey...

------------------------------

From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Low level serial driver not getting ioctl()
Date: Thu, 05 Apr 2001 21:35:42 GMT

In article <Ur5z6.11087$[EMAIL PROTECTED]>, Grant Edwards wrote:

>>How do I get the mid-level serial driver to notify me of all
>>setattr() calls?

I think it is calling my set_termios() function as it should
(and the set_termios() funciton is where the bug is).  I've
spent the afternoon pulling my hair out trying to figure out
what was wrong with my ioctl() function -- and why it wasn't
getting called.

In my best Don Adams voice:

 "Never Mind."

-- 
Grant Edwards                   grante             Yow!  Give them
                                  at               RADAR-GUIDED SKEE-BALL
                               visi.com            LANES and VELVEETA
                                                   BURRITOS!!

------------------------------

From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: 
alt.computer.drivers,alt.os.linux,aus.computers.linux,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: Win Modems
Date: 5 Apr 2001 21:39:55 GMT

In <[EMAIL PROTECTED]> Michael Meissner <[EMAIL PROTECTED]> writes:

]Johan Kullstam <[EMAIL PROTECTED]> writes:

]> "LittleFish" <littlefish_au[SPAM ME AT YOUR OWN RISK]@yahoo.com> writes:
]> 
]> one word _EXTERNAL_.  yes, i know you said internal but why not expand
]> your possibilities?  since most mice these days are ps/2 or usb, you
]> probably have nothing on your rs232 ports.  why not use it?

Internal are fine, as long as you make sure that the modem is a real
modem, not some sort of winmodem. Ie it should state that it works under
Linux or under real DOS (not the DOS under windows). Get a return policy
to make sure that it works under Linux. 



Basically if you can persuade it to dial out under Linux, then it should
work.


------------------------------

From: [EMAIL PROTECTED] ()
Subject: Re: Kernel Panic in Network Interface
Date: Thu, 05 Apr 2001 21:54:57 -0000

In article <[EMAIL PROTECTED]>,
James Stephens  <[EMAIL PROTECTED]> wrote:

>No, I have not... there is no "linux-up" option in lilo.conf... do I just
>need to recompile the kernel and select NO to smp modules???

Yes

--
http://www.spinics.net/linux/

------------------------------

From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Kernel Panic in Network Interface
Date: 5 Apr 2001 22:28:28 GMT

In article <[EMAIL PROTECTED]>,
James Stephens  <[EMAIL PROTECTED]> wrote:
| No, I have not... there is no "linux-up" option in lilo.conf... do I just
| need to recompile the kernel and select NO to smp modules???
| 
| btw, I from a workstation I can ping the problem server and get responses
| but I cannot telnet to the box...

The 2.4 kernel supports "nosmp" as an option at boot time, but for the
old kernel... who knows? I certainly don't remember that option, but I
find new old features in linux all the time.

No, as for TR in 2.2, that's an inteesting thought, because I've got a
machine like that, with a TR and two 100TX NICs, and it dies regularly.
But may 8-10 times a week, not on short term. I had assumed that it was
because there are some fixes for that hardware in newer kernels, I just
couldn't get them running with TR+100Mbit in the length of time I can
keep the machine down.

Are you explicitly configuring the card with isapnp? That was one of the
steps I used, because the IBM stuff (LANAID??) did something odd when I
used that. I just build a config and slamed it into the PnP cards at
boot time. I'm running a 2.2.13 with RAID and other patches, and while
I'd love to get a new kernel in, until I replace the machine and
redeploy it, that's not likely.

Hope any of this helps.

-- 
  bill davidsen <[EMAIL PROTECTED]>  CTO, TMR Associates, Inc
At LinuxExpo Sun was showing Linux applications running on Solaris.
They don't get it, the arrow points the other way. There's a reason why
there's no SolarisExpo, Solaris is a tool; Linux is a philosophy, a
religion, a way of life, and only incidentally an operating system.

------------------------------

From: [EMAIL PROTECTED]
Subject: RE: usleep() is unreliable when sleeping for less then 10000 micro
Date: Fri, 06 Apr 2001 00:10:53 GMT


RE: usleep() is unreliable when sleeping for less then 10000 micro
sec...

Thanks for reading this,

I noticed that usleep() is completly unreliable when sleeping for less
then 10000 micro sec.
Do you know of another way of sleeping... lets say for 10 micro
seconds...

Again, thanks for your help and be sure to visit my we site at
http://64.34.162.237.

Born2net.


------------------------------

Subject: 2.4.3 and initrd problem - fixed
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (bill davidsen)
Date: Fri, 06 Apr 2001 01:21:54 GMT

PROBLEM:

  kernel 2.4.3 will not boot on systems with initrd files

DESCRIPTION

  Building kernel 2.4.3 and attempting to boot it failed. The problem
turned out to be in the modutils-2.4.5 rpm for i386.

DETAIL

  After building the 2.4.3 kernel and moving the boot modules to the
initrd image, it was noted the the system stopped when trying to load
modules for the root filesystem device. First solution attempted was to
get the i386 rpm from kernel.org for the latest (2.4.5) modutils and
install, copying the insmod program to the initrd image.

  This fails, with the message "insmod: no such program" at boot.
Examination showed that the binary provided was not static linked. Got
the source from kernel.org and built. By default this still isn't static
linked! Changed the common Makfile to set LDFLAGS to "-static -s" and
built again. After install and copy to initrd image this resulted in a
bootable system.

  While it is possible to copy the libraries needed to the initrd image,
it becomes larger than the default ramdisk size (at least on my system).
And including the drivers in the kernel hurts portability and makes the
kernel too large to boot from floppy.

SYSTEMS AFFECTED

  Redhat 7.x and similar using configurations which have the root device
driver loaded from modules.

SUGGESTED FIX

  None needed, but the kernel "Changes" file should include a note that
people using initrd will need to rebuild them static along with the note
that a newer modutils is needed. Even for people who build their own
initrd files, this is NOT obvious!
-- 
bill davidsen <[EMAIL PROTECTED]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

------------------------------

From: <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux Device
Date: Thu, 5 Apr 2001 19:21:33 -0700

Dear Jan:
    I believe that you can find some useful information in the
linux/arch/arm subdirectory tree. There are examples of various ARM
architectures including the ebsa285 and the assabet. If I recall correctly,
assabet is ARM7. It appears to me that if you start by studying the ARM
implementation that you can go a long way to answering your questions.

"Jan Pietrusky" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hello,
> I would like to design a embedded linux board with ARM7TDMI.  I use
> enough FLASH and SD-RAM for my design. Does anyone know, how is the
> memory map of the linux? Which region of the memory contain the external
> peripherie? How execute the boot process, should I use a boot eprom(
> similar bios at PC)?
> Thanks for all hints.
>
> Jan
> --
>  ---------------------------------------------------------------------
> | Dipl.-Ing.(FH) Jan Pietrusky             | Tel: +49 (0) 3677 678331 |
> | Institut fuer Mikroelektronik- und       | FAX: +49 (0) 3677 678338 |
> | Mechatronik-Systeme                      |                          |
> | Langewiesener Strasse 22, 98693 Ilmenau  |                          |
> |---------------------------------------------------------------------|
> | MAIL/WWW: [EMAIL PROTECTED], http://www.imms.de/                |
>  ---------------------------------------------------------------------
>



------------------------------

From: "Joseph A. Knapka" <[EMAIL PROTECTED]>
Subject: Re: Embedded Linux development?
Date: Fri, 06 Apr 2001 02:07:42 GMT

This is a very peculiar attitude put forth by RLC. Linux runs on a
number
of embedded processors.

http://www.rtlinux.org/
http://www.linuxce.org/
http://linuxsh.sourceforge.net/
http://www.embeddedlinux.org/
http://www.azpower.com/mylinux/

If RLC releases information about the hardware configuration
of their board, I'm sure any number of people (I can only speak
for myself, of course) would be delighted to build a Linux port.
Even if they don't release hardware docs, I expect Linux will
run on it sooner or later.

What CPU is the board based on?

-- Joe

"Mr. Oogie Boogie" wrote:
> 
> R.L.C. Enterprises (www.RLC.com) makes a really nice single board
> computers with touch screen lcd's (CE-SBC-SC400) for a reasonable
> price (which is exactly what I'm looking for).  The problem is that it
> comes with Windows CE (which I wont touch).  When I asked them about
> Linux support this was their reply:
> 
> "There is a lot of talk and interest in using Linux on our embedded
> computers, but as of yet we have not located a company which supports
> a
> truly embedded version of the product suitable for embedded
> controllers like
> the ones we manufacture.  Our products are fully supported using
> Windows CE
> as well as Visual basic and Visual C++ for application program
> development.
> If you know of a company with the same type of support and can furnish
> a
> platform builder for porting Linux  to a truly embedded controller.
> Not just
> another PC platform, we would be extremely interested. I am not sure
> it
> exist or is even possible at this time though.
> 
> Thank You for Your Interest.
> 
> Robert"
> 
> Their email is [EMAIL PROTECTED] if you have helpful advice.
> 
> --
> Ralph A. Preston
> The MITRE Corporation
> 202 Burlington Road, MS E015
> Bedford, MA 01730-1420

-- Joe Knapka
"It was just a maddened crocodile hidden in a flower bed. It could
 have happened to anyone." -- Pratchett
// Linux MM Documentation in progress:
// http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
* Evolution is an "unproven theory" in the same sense that gravity is. *

------------------------------

From: "tlin" <[EMAIL PROTECTED]>
Subject: How to control time irq
Date: Thu, 5 Apr 2001 23:39:06 -0600

I want to set very small time interval and let my thread sleep
for that amount of time. When the irq occurs, my thread will
be woke up. This is a thread created by a kernel module.

Please give me some hints or webs, thanks!



------------------------------

From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: Zombies and daemons
Date: Fri, 06 Apr 2001 08:12:06 +0200

Craig Orsinger wrote:
> =

> In article <[EMAIL PROTECTED]>, "Josef Moellers"
> <[EMAIL PROTECTED]> wrote:
> =

> > Hubert wrote:
> >
> >> I am almost sure, that there are more (perhaps more sophisticated) w=
ays
> >> to achieve this.  Does anybody have a better way? I still do not
> >> understand, why in my first tries calling waitpid() returns  -1.
> >
> > One can set up a signal handler for SIGCHLD which then calls wait() t=
o
> > eliminate the zombie.
> =

>         If you are just using wait() to get rid of the zombie (IOW, to =
handle
> SIGCHLD to make the child process go away), then you can just use
> signal(SIGCHLD, SIG_IGN) to ignore the SIGCHLD signal. Read the
>  man page on signal(2) for an explanation of how to do this.

My signal(2) man page says:
       According to POSIX (B.3.3.1.3) you must not set the action
       for SIGCHLD to SIG_IGN. Here the BSD and  SYSV  behaviours
       differ,  causing  BSD  software  that  sets the action for
       SIGCHLD to SIG_IGN to fail on Linux.

-- =

Josef M=F6llers (Pinguinpfleger bei FSC)
        If failure had no penalty success would not be a prize
                                                -- T.  Pratchett

------------------------------

From: "Lee Ho" <[EMAIL PROTECTED]>
Subject: Re: 2.4 kernels
Date: Fri, 06 Apr 2001 06:31:25 GMT


I wrote brief introduction about porting to 2.4.
There is block device driver chapter, but it is incomplete, and
would be under estimated (for me, i have no time to upgrade it).
Anyway i hope it would be helpful to you.

http://linuxkernel.to/module/port-2.4/eng/

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Lee, Ho. Software Engineer, Embedded Linux Dep, LinuxOne
Mail : [EMAIL PROTECTED] (work), [EMAIL PROTECTED] (personal)
Homepage : http://flyduck.com, http://linuxkernel.to

Mike Austin Wrote:
>Is there a good guide on 2.4 device drivers, or a porting guide for porting
>a device driver from 2.2 to 2.4?  Specifically, block devices?  I haven't
>been able to find a good guide, and I would like one before the second
>edition of "Linux Device Drivers" comes out.  Thank you!
>Michael Austin




------------------------------

From: Pasztor Szilard <[EMAIL PROTECTED]>
Subject: Re: usleep() is unreliable when sleeping for less then 10000 micro
Date: 6 Apr 2001 07:06:13 GMT

[EMAIL PROTECTED]:
> RE: usleep() is unreliable when sleeping for less then 10000 micro
> sec...
> 
> Thanks for reading this,
> 
> I noticed that usleep() is completly unreliable when sleeping for less
> then 10000 micro sec.

That's because if the sleep delay exceeds the time slice, the kernel will
only return the cpu to your process via its 100Hz timer.

Look at Documentation/rtc.txt, it might help you. I'm still searching for
some more flexible solution, too.

            -------------------------------------------------------
            |    Widows '95 - The Micro$oft Solution Preventer    |
            -------------------------------------------------------

------------------------------

From: afausti <[EMAIL PROTECTED]>
Subject: Re: Kernel Routing Question
Date: Fri, 06 Apr 2001 09:32:20 +0200

Tom wrote:

> In a Linux box, if a IP packet is generated by the higher layer or received
> from one network card, and its destination is another host, then this packet
> will be forwarded to the proper network card.
>
> Can anyone told me which function do the final step: dequeue the packet from
> the buffer queue and send it to the proper network device?
>
> In fact, the idea is I want to skip the routing inside the Linux and forward
> the packet directly to a network card without checking it. So I need to call
> this function directly when I get a IP data packet. But the functions I
> found now are all working on the IP layer or require to build information of
> routings into the packet.
>
> Thanks for any help or suggestion!

I am not sure but it seems to be "dev_queue_xmit()" in net/core/dev.c
to be sure try to find out a copy of
Glenn Herrin  called "Linux IP Networking"
Bye.


------------------------------

From: "Brian Bisaillon" <[EMAIL PROTECTED]>
Subject: Re: Zombies and daemons
Date: Fri, 06 Apr 2001 07:51:53 GMT

Well, if you're getting zombies you did something wrong because your threads
are not exiting properly. It's not good practice to start killing zombies
but rather to avoid creating zombies in the first place. Rework your code
and see if you can't get rid of the zombie problem entirely.

"Hubert" <[EMAIL PROTECTED]> wrote in message
news:9ahdvf$8gf$[EMAIL PROTECTED]...
> Hi all,
>
> I cannot remove a zombie created by a daemon from the process list.
>
> My daemon (using pthreads) creates a child process within one of its
threads
> by calling vfork() and execv(). After the child process terminates, it is
> converted to a zombie.
> The same thread that creates the child process tries to remove the zombie
by
> calling waitpid(pid_t,&status,0) but always gets a return value of -1.
> I also tried to call vfork() twice (found this described in some manuals)
to
> make the init process responsable for the zombie, but it did not work.
>
> How can I remove a zombie created by a daemon? Should I also daemonize the
> child or is there a better way?
>
> Thank you
>
> Hubert
>
>
>
>



------------------------------

From: "Brian Bisaillon" <[EMAIL PROTECTED]>
Subject: Re: 2.2.19 ( and older ) bug with Via KT133 ( dunno 'bout KT133A, eh? )
Date: Fri, 06 Apr 2001 07:56:29 GMT

Well, in my experience I found that it was better NOT to enable DMA by
default. For example, when I enabled DMA by default it picked up my drive as
UDMA Mode 2 via hdparm's statistics on /dev/hdx but when I recompiled the
kernel without DMA enabled by default, it picked up my drive as UDMA Mode 4
(that is what it's supposed to be) and so I just fed the rest of the
configuration options via hdparm afterwards.

"D.A.M. Revok" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm not a programmer, just a configuration-hacker, so I've gone as far as
I can
> with this, sorry.
>
> With Asus A7V, cheapest Thunderbird I could get ( 700 ), and the fastest
quiet
> new HD ( IBM 75GXP-45Gig ) I could get, along with an old Fujitsu
MPE-10Gig
> drive, I've discovered this:
>
> When using Caldera eDesktop 2.4's hackified 2.2.14 kernel, OR the latest
2.2.19
> kernel ( or any in-between, compiled on the Caldera-gcc, I tried the new
2.95.3,
> but couldn't get the 3com 3c90x module to compile with it, so I ditched
that
> idea --but maybe recompiling the glibc after gcc, and before the kernel &
> module. . . <sigh> ) one need set the BIOS to UDMA-1 for any UDMA-5 (
ATA100 )
> drive and UDMA-0 for any actually-UDMA-4 ( ATA66 ) drive ( note that
pattern,
> eh? ).
>
> Doing this results in
> a) about 12-17MB/s ( hdparm t /dev/hdx ) buffered-disk-reads, and
> b) NO DATA CORRUPTION, and
> b) relief from the 1.99-3.65MB/s one gets at, dig this, /all/ higher UDMA
> settings ( without hdparm -d. . .  ).
>
> Yeah, when I compiled the kernel I chose Via-chipset support and
> DMA-enabled-by-default.
>
> running KTop ( KDE-1.1.2 ) when doing a basic diff of cd-iso images ( for
> testing I cp'ed a couple of images from dir to dir and diff'ed 'em ) I saw
that
> the system ( red portion of the CPU-usage ) was around 50%, yet when I
reduced
> the BIOS settings as indicated above things sped-up /very/ nicely ( for a
buggy
> condition, anyways ).
>
> If I run hdparm -d1 -c3 -u1 -m16 /dev/hdx, in /etc/rc.d/rc.boot, then I
get the
> more reasonable 33MB/s ( with the higher BIOS settings ), but I'm not sure
I
> want to gamble my system's integrity when booting ( until that 'hdparm'
point ),
> and I'm CERTAINLY not willing to gamble my system's integrity while
installing.
>
> If you're installing linux on a Via chipset, then /please/ set down your
BIOS
> settings for your drives this way, before installing, and then after
you've got
> it running ( and your install-scripts fixed-up ), /then/ put back the
higher
> settings ( if you want ), eh?
>
> Cheerses, and PS: the 3c59x driver doesn't work with the latest
3c905C-series
> cards, and the 3c905C module from 3com isn't integrated with the kernel. .
. 
>
> <trying not to wail melodramatically> Please someone fix that. . .
>
>
> Ahem.
>
>
> Right, and thanks people, I /love/ not having to live-in windows
>  ( Freedom == Autonomy )
>
>          \m
>
>
> Anyone wanting to contact me, please do so directly, since I don't bother
with
> usenets much anymore, and this group's over-my-head, anyways  : )



------------------------------

From: "Brian Bisaillon" <[EMAIL PROTECTED]>
Subject: Re: kernel panic, killing interrupt handler
Date: Fri, 06 Apr 2001 07:58:04 GMT

I would try compiling your NIC drivers into the kernel instead of running
them as modules. Maybe that will solve the problem.

<[EMAIL PROTECTED]> wrote in message
news:9ag7mb$5d3$[EMAIL PROTECTED]...
> I've got 4 ethernet adapters in PCI and video adapter in PCI. All PCI
> slots are busy.
> Kernel 2.4.2
> two ne-2k and two rtl 8139
> Server is a gate to Internet for e.g 200 computers in LAN.
> Sometimes (probably when the traffic is huge) my server
> crashes and I get such error:
>
> Code: 89 72 04 89 15 C0 BD 25 C0 C7 00 00 00 00 00 C7 40 04 00 00
> Kernel panic: Aiee, killing interrupt handler
> In interrupt handler - not syncing
>
> I used ksymoops and I got:
> ksymoops 2.3.7 on i686 2.4.2.  Options used
>      -v /usr/src/linux/vmlinux (specified)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.2 (specified)
>      -m /boot/System.map (specified)
>
> Warning (compare_maps): mismatch on symbol __module_author  , 8139too says
c883bd00, /lib/modules/2.4.2/net/8139too.o says c8839040.  Ignoring
/lib/modules/2.4.2/net/8139too.o entry
> Warning (compare_maps): mismatch on symbol __module_description  , 8139too
says c883bd40, /lib/modules/2.4.2/net/8139too.o says c8839080.  Ignoring
/lib/modules/2.4.2/net/8139too.o entry
> Warning (compare_maps): mismatch on symbol
__module_parm_max_interrupt_work  , 8139too says c883bd90,
/lib/modules/2.4.2/net/8139too.o says c88390d0.  Ignoring
/lib/modules/2.4.2/net/8139too.o entry
> Warning (compare_maps): mismatch on symbol __module_parm_media  , 8139too
says c883bdaa, /lib/modules/2.4.2/net/8139too.o says c88390ea.  Ignoring
/lib/modules/2.4.2/net/8139too.o entry
> Warning (compare_maps): mismatch on symbol
__module_parm_multicast_filter_limit  , 8139too says c883bd72,
/lib/modules/2.4.2/net/8139too.o says c88390b2.  Ignoring
/lib/modules/2.4.2/net/8139too.o entry
> Warning (compare_maps): mismatch on symbol __module_author  , ne2k-pci
says c8836e40, /lib/modules/2.4.2/net/ne2k-pci.o says c8837220.  Ignoring
/lib/modules/2.4.2/net/ne2k-pci.o entry
> Warning (compare_maps): mismatch on symbol __module_description  ,
ne2k-pci says c8836e80, /lib/modules/2.4.2/net/ne2k-pci.o says c8837260.
Ignoring /lib/modules/2.4.2/net/ne2k-pci.o entry
> Warning (compare_maps): mismatch on symbol __module_parm_debug  , ne2k-pci
says c8836ea4, /lib/modules/2.4.2/net/ne2k-pci.o says c8837284.  Ignoring
/lib/modules/2.4.2/net/ne2k-pci.o entry
> Warning (compare_maps): mismatch on symbol __module_parm_full_duplex  ,
ne2k-pci says c8836ec3, /lib/modules/2.4.2/net/ne2k-pci.o says c88372a3.
Ignoring /lib/modules/2.4.2/net/ne2k-pci.o entry
> Warning (compare_maps): mismatch on symbol __module_parm_options  ,
ne2k-pci says c8836eb1, /lib/modules/2.4.2/net/ne2k-pci.o says c8837291.
Ignoring /lib/modules/2.4.2/net/ne2k-pci.o entry
> Code: 89 72 04 89 15 C0 BD 25 C0 C7 00 00 00 00 00 C7 40 04 00 00
> Using defaults from ksymoops -t elf32-i386 -a i386
>
> Code;  00000000 Before first symbol
> 00000000 <_EIP>:
> Code;  00000000 Before first symbol
>    0:   89 72 04                  mov    %esi,0x4(%edx)
> Code;  00000003 Before first symbol
>    3:   89 15 c0 bd 25 c0         mov    %edx,0xc025bdc0
> Code;  00000009 Before first symbol
>    9:   c7 00 00 00 00 00         movl   $0x0,(%eax)
> Code;  0000000f Before first symbol
>    f:   c7 40 04 00 00 00 00      movl   $0x0,0x4(%eax)
>
>
> 10 warnings issued.  Results may not be reliable.
>
>
>
> but I don't know what to do with it and where to look for a reason.
> Please help. I would prefer answers to priv.
>
> --
> dziadzi



------------------------------

From: "Brian Bisaillon" <[EMAIL PROTECTED]>
Subject: Re: mysql or postgresql? which is better?
Date: Fri, 06 Apr 2001 08:01:13 GMT

Yes it does, if you get the patched version of MySQL with transaction
support. It does exist...

<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> In article <9aakvc$jbh$04$[EMAIL PROTECTED]>,
> Hans-Peter Maurer <[EMAIL PROTECTED]> wrote:
>
> >which is better mysql or postgresql? Which is more reliable and more
> >powerful...?
>
> It depends on what you want to do.  If all you want is good read
> performance, mysql is better.  But mysql doesn't do transactions
> which is a major problem if you ever do concurrent updates.
>
> --
> http://www.spinics.net/linux/



------------------------------

From: "Brian Bisaillon" <[EMAIL PROTECTED]>
Subject: Re: mysql or postgresql? which is better?
Date: Fri, 06 Apr 2001 08:02:41 GMT

I would personally go with MySQL. I even use phpMyAdmin which allows me to
administer my MySQL databases from the web. It's sweet...

"Hans-Peter Maurer" <[EMAIL PROTECTED]> wrote in message
news:9aakvc$jbh$04$[EMAIL PROTECTED]...
> Hello world!
>
> i am looking for the best free database for linux:
>
> which is better mysql or postgresql? Which is more reliable and more
> powerful...?
>
> Thanks in advance!
>
> best from germany
>
> Peter
>
>



------------------------------

From: "Brian Bisaillon" <[EMAIL PROTECTED]>
Subject: Re: How to setup VPN in linux?
Date: Fri, 06 Apr 2001 08:04:18 GMT

I don't know off the top of my head but look into VPN software by searching
Freshmeat. You should find some stuff there (http://www.freshmeat.net).

"Jimmy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi all,
>
>     I want to know how to setup VPN using ethertap. Can someone show me
> the steps in doing that?
>
> Jimmy
>



------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to