Linux-Development-Sys Digest #19, Volume #8 Thu, 13 Jul 00 14:13:17 EDT
Contents:
When We will use the static library ? ([EMAIL PROTECTED])
Re: 2.2.15-Lockup with PLX9050-based PCI card (Adrian Cox)
Using _GNU_SOURCE macro ok? ("Timo Volkmer")
Re: 2.2.15-Lockup with PLX9050-based PCI card (Wesley Hosking)
Re: 2.2.15-Lockup with PLX9050-based PCI card (Andy Thaller)
Re: 2.4.0test2 and pppd ("Michael Faurot")
Re: Using _GNU_SOURCE macro ok? (Andreas Jaeger)
Race condition with MOD_INC_USE_COUNT? (Guy Bolton King)
Re: are PCI drivers char drivers? (Grant Edwards)
Re: 2.2.15-Lockup with PLX9050-based PCI card (Andy Thaller)
Re: Problems with modules on 2.2.13 [SMP] (Paul Kimoto)
Re: keyboard with additional function keys ("LY")
Re: Good Basic compiler for linux? (Marc SCHAEFER)
Re: linker problem? ("Norm Dresner")
Re: NFSRoot problems (root)
Re: keyboard with additional function keys (Paul Fox)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: When We will use the static library ?
Date: Thu, 13 Jul 2000 08:07:41 GMT
Hi!!
Under the /usr/lib there are many *.a and they are very big :-(
Are they useful? What kind of situation we will use them,
Can I kill all of them? I had been move them to other place,
It looks ok ...., Thanks your help!!
Please cc: [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Adrian Cox <[EMAIL PROTECTED]>
Subject: Re: 2.2.15-Lockup with PLX9050-based PCI card
Date: Thu, 13 Jul 2000 10:17:56 +0100
Reply-To: Adrian Cox <[EMAIL PROTECTED]>
Andy Thaller wrote:
> In case it's of any help: lspci -vv shows the following informations:
>
> 00:0a.0 System peripheral: PLX Technology, Inc. PCI <-> IOBus Bridge (rev 02)
> Subsystem: PLX Technology, Inc.: Unknown device 9050
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin A routed to IRQ 9
> Region 1: I/O ports at b800
> Region 2: I/O ports at b400
> (00:0a.0 being the card of interest, the other plx-based board has a different
> function)
Just because a card is based on a PLX chip doesn't mean that it has to
have the PLX vendor ID. The vendor of the card is supposed to put their
own vendor ID and device ID into config space to avoid just this sort of
confusion.
A PLX 9050 can lockup the PCI bus if the bus on the other side of it
locks. Thus, if you do something the logic on the card doesn't support,
the PC will lock up.
Can you run the dos versions under dosemu, or under a dos debugging
tool, to trace their PCI accesses? They may be doing more than what the
manual claims.
- Adrian Cox, AG Electronics
------------------------------
From: "Timo Volkmer" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Using _GNU_SOURCE macro ok?
Date: Thu, 13 Jul 2000 12:59:39 +0200
Hi there,
I am currently porting an application from HP-UX to Linux using SuSE-Linux
6.4 (Kernel 2.2.14 and gcc 2.95.2).
Due to some differences of the definition of system functions and constants
we set the _GUN_SOURCE macro while we compile under Linux.
Is this a common way to go, or is there perhaps another (higher-level) macro
to set?
Might there be a different (better) way to solve such problems?
I am just courious and want to avoid running into more problems while using
this macro.
Thanks !!!
-Timo.
------------------------------
Subject: Re: 2.2.15-Lockup with PLX9050-based PCI card
From: Wesley Hosking <[EMAIL PROTECTED]>
Date: 13 Jul 2000 10:49:25 +0930
Andy Thaller <[EMAIL PROTECTED]> writes:
> Hi,
>
> I'm having severe problems with a PLX9050 based PCI-card featuring a 32
> channel A/D.
>
> I'm trying to write a device driver on my 2.2.15 i386 box. I have no problem
> initializing the card and reading any of the 32 channels which involves
> writing to certain I/O mapped registers and reading from others. The base
> address assigned to the card is 0xb400 and the working I/O addresses are in
> the range 0xb400..0xb403. To switch the card to another operational mode,
> however, it is necessary to write the mode byte to address 0xb40e which always
> leads to an immediate system lockup independent of the mode byte value (e.g.
> also when setting the very same mode the card has as bootup default)
>
> The card's manufacturer refuses to help me saying they only support DOS but I
> need to get this card up and running. The hardware must be ok for the example
> DOS programs work as they should.
>
> What could possibly go wrong, here, Does anyone know if te PLX chip needs some
> special treatment on initialisation? Any PCI commands to be set or unset? I
> followed the hints from Documentation/pci.txt but since this is my first PCI
> device driver, I'm at a complete loss at this point.
>
The main thing would be to get the documentation for the
registers (from the PLX web site ). Their are drivers in the Linux kernel
that use the PLX DMA chip (an ethernet driver ) - you might want to start
there....
wes
------------------------------
From: Andy Thaller <[EMAIL PROTECTED]>
Subject: Re: 2.2.15-Lockup with PLX9050-based PCI card
Date: Thu, 13 Jul 2000 15:56:17 +0200
Reply-To: [EMAIL PROTECTED]
Adrian Cox wrote:
>
> Can you run the dos versions under dosemu, or under a dos debugging
> tool, to trace their PCI accesses? They may be doing more than what the
> manual claims.
>
This sounds like an interesting aproach :-) What exactly would I do to trace
the PCI accesses? I gather there would be quite some on my system so is there
a way to filter out the accesses to just one device or how does this work? How
in particular would I have to configure dosemu to give the program access to
the hardware? Alternatively, what kind of dos debugging tool would you
suggest?
Regards,
Andy
--
Andy Thaller
TU Muenchen, Physikdepartment E11 Tel: ++49 (0)89 289 12860
James Franck Str. Fax: ++49 (0)89 289 12842
85748 Garching // Germany email: [EMAIL PROTECTED]
------------------------------
From: "Michael Faurot" <[EMAIL PROTECTED]>
Subject: Re: 2.4.0test2 and pppd
Date: 13 Jul 2000 14:11:50 GMT
bill davidsen <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>,
: [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
: | I think I need to use ppp-on (edited) in conjunction w/
: | ppp-dialing-scripts (or some such, edited as well). Can anyone give me
: | some pointers? Merci beaucoup.
: I typed in some things which have my 2.4.0test2ac2 working, but your
: address bounced and I'm damned if I'll type it again. People who ask
: for help with a bogus address get none from me. Learn to use hotmail
: or such when you ask for help. You get all the privacy in the world
: from me, including never seeing your posts.
This is a newsgroup, not a mailing list. Post your reply in the group
and let everyone that reads it benefit from it.
--
==============================================================================
Michael | mfaurot | Build a system that even a fool can use and only a
Faurot | atww.net | fool will want to use it.
------------------------------
From: Andreas Jaeger <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Using _GNU_SOURCE macro ok?
Date: 13 Jul 2000 16:22:13 +0200
>>>>> Timo Volkmer writes:
> Hi there,
> I am currently porting an application from HP-UX to Linux using SuSE-Linux
> 6.4 (Kernel 2.2.14 and gcc 2.95.2).
> Due to some differences of the definition of system functions and constants
> we set the _GUN_SOURCE macro while we compile under Linux.
> Is this a common way to go, or is there perhaps another (higher-level) macro
> to set?
_GNU_SOURCE is the most general macro. See <features.h> and the
manual for an explanation of all feature test macros (e.g. run
info libc "Feature Test Macros")
> Might there be a different (better) way to solve such problems?
> I am just courious and want to avoid running into more problems while using
> this macro.
If you're porting from HP-UX, I guess you can use some less general
macros - this makes porting back easier.
> Thanks !!!
Andreas
--
Andreas Jaeger
SuSE Labs [EMAIL PROTECTED]
private [EMAIL PROTECTED]
------------------------------
From: Guy Bolton King <[EMAIL PROTECTED]>
Subject: Race condition with MOD_INC_USE_COUNT?
Date: Thu, 13 Jul 2000 15:32:22 +0100
I've written a device driver that implements a procfs file for looking
at various kernel structures that are not otherwise visible. The code
uses the create/remove_proc_entry API and provides an implementation of
proc_dir_entry::read_proc.
The question: am I right in thinking that there is a race condition in
this code when running on SMP boxes? i.e. even if my read_proc
implementation begins with MOD_INC_USE_COUNT and ends with
MOD_DEC_USE_COUNT, isn't it possible for the module to be removed by
rmmod running on another processor _after_ entry to read_proc but
_before_ MOD_INC_USE_COUNT is called? Or does the kernel know when it
is calling into a module, and temporarily increase the use count anyway
(From a reading of the kernel sources, I don't think it does do this)?
If this is the case, won't the race condition extend to _any_ module
entry-point?
Thanks in advance for any light shed,
Guy.
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: are PCI drivers char drivers?
Date: Thu, 13 Jul 2000 15:27:22 GMT
In article <[EMAIL PROTECTED]>, Zoran Cutura wrote:
>Usually we distinguish between character drivers and block
>drivers because these use different interface functions from
>kernel to user space. However a SCSI-driver with the low level
>control functions will most likly not be used directly from
>userspace but thru a filesystem or a generic SCSI-device where
>one of these is a block device but the other is a character
>device. So when one talks about character devices or block
>devices one is only talking about the interface of the driver
>to the user space.
Exactly.
>From what you've explained I understand your term SCSI-driver
>beeing the functionality needed to control the SCSI-bus and
>connected devices, where we need to bare in mind, that
>certainly this differs for all devices and most likly does not
>have a interface to user space.
Correct. The device driver for a PCI SCSI board (remember,
we're talking about drivers for PCI boards) uses neither the
char nor block device drivers interface. It has an interface
to the middle-layer SCSI stuff in the Linux kernel. PCI SCSI
board drivers are not char drivers, and they are not block
drivers, they're SCSI board drivers -- it's whole different
category. Likewise, drivers for PCI Ethernet boards aren't
char drivers and they aren't block drivers, they're network
drivers.
I'm defending the statement that for PCI boards, network
drivers and SCSI drivers are neither char nor block drivers,
they're network drivers and SCSI drivers.
The original poster wanted to know whether a PCI driver should
be a char or block device. Somebody replied that it depended
on the device, and it might be neither if it was a network or
SCSI board.
Then somebody asserted that everything was either a char or
block device and that SCSI board drivers were char devices. I'm
claiming this last assertion is wrong.
I am claiming that drivers for PCI boards come in (at least) 4
flavors: char drivers (serial boards), block drivers (IDE or
goofy CD drives?), network drivers (Ethernet boards), SCSI
drivers (SCSI boards). Each of these types of drivers presents
a distinct interface to the system. The char and block driver
interface is presented to the user with little intervening
manipulation, and the operations implimented in the driver map
almost 1:1 to system calls and then to libc calls like open(),
close(), read(), write(), ioctl(). Network and SCSI drivers,
OTOH, interface to several intermediate layers of software in
the kernel, and the interface presented to the user by those
upper layers is quite different than the interface implimented
by the drivers.
--
Grant Edwards grante Yow! I am covered with
at pure vegetable oil and I am
visi.com writing a best seller!
------------------------------
From: Andy Thaller <[EMAIL PROTECTED]>
Subject: Re: 2.2.15-Lockup with PLX9050-based PCI card
Date: Thu, 13 Jul 2000 17:58:55 +0200
Reply-To: [EMAIL PROTECTED]
Adrian Cox wrote:
>
> Can you run the dos versions under dosemu, or under a dos debugging
> tool, to trace their PCI accesses? They may be doing more than what the
> manual claims.
>
Oh Yes!!! It runs perfectly, I had to $_ports = "0xb400 0xb401 0xb402 0xb403
0xb40e" in the dosemu.conf after the driver tried to access those ports (btw,
they're the same as those my linux-device-driver uses) and the example rograms
run perfectly within dosemu. Now I only need to extract what the dosprogram
does to achieve this... After enabling read/write access to those ports they
aren't any longer mentioned in the debug messages - so how can I find out what
the driver does to the card and/or the pci system?
Andy
--
Andy Thaller
TU Muenchen, Physikdepartment E11 Tel: ++49 (0)89 289 12860
James Franck Str. Fax: ++49 (0)89 289 12842
85748 Garching // Germany email: [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Crossposted-To: comp.os.linux.misc
Subject: Re: Problems with modules on 2.2.13 [SMP]
Date: 13 Jul 2000 12:34:04 -0500
Reply-To: [EMAIL PROTECTED]
In article <8k59fm$glb$[EMAIL PROTECTED]>, Chris J/#6 wrote:
> There is, at work, a Dell Poweredge, Dual PIII 450, Megaraid RAID, bags
> of memory and disk etc etc. But I've been unable to get modules to insert
> into the kernel, with messages from insmod "unresolved symbol". The system
> is a RedHat 6.1 Deluxe installation...and its the supplied Redhat kernel.
> Personally, I'd like to blow it away and stick a stock non-vendor-modified
> 2.2.14 on it, but I've been told not to do that... *sigh*.
>
> Here is, for example, the output of "insmod loop":
>
> /lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_memcpy
> /lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_memset
> /lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_copy_to_user
> /lib/modules/2.2.13-0.13/block/loop.o: unresolved symbol best_copy_from_user
>
> Now, from what I can tell, these are standard kernel functions, and whats
> more, "grep best_mem /boot/System.map" reveals ...
>
> c0220384 T best_memcpy
> c022040f t best_memcpy_final
> c0220437 T best_memset
> c02204bf t best_memset_final
[...]
> So its in the kernel...however, I'm wondering if there is some obfuscation
> going on somewhere, as doing ksysms -a and feeding that through grep reveals
>
> c0220384 best_memcpy_R__ver_best_memcpy
> c0220437 best_memset_R__ver_best_memset
>
> Both at the same offset as the output from System.map ... is this causing
> the problem -- same symbol but different name ?
>
> Basically, module loading is broken and I can't figure out whats gone wrong.
> Yes, I've done from clean, zapped the modules tree before a make
> modules_install.
>
> depmod -a fails everytime (unresolved symbols in every module), so its well
> and truely fubar'd.
Could this be a problem with CONFIG_MODVERSIONS? (However, I thought that
then the symbols usually looked more mangled ...)
--
Paul Kimoto
------------------------------
From: "LY" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development,comp.os.linux.hardware
Subject: Re: keyboard with additional function keys
Date: Thu, 13 Jul 2000 18:12:42 +0200
I've used xev. The program gives me two (4 for Press/Release) identical
scancodes.
I want to use this sequence of scancodes as an unique scancode.
However, thanx for your answer.
------------------------------
From: Marc SCHAEFER <[EMAIL PROTECTED]>
Subject: Re: Good Basic compiler for linux?
Date: 13 Jul 2000 11:35:34 GMT
bill davidsen <[EMAIL PROTECTED]> wrote:
: I think I'll be taking a look at C# anyway, it may well be a standard
: language five years from now.
We'll see in 5 years from now. However, I hereby predict that
you won't find open compilers for it, and that most of its useful
features will come from proprietary libraries.
------------------------------
Reply-To: "Norm Dresner" <[EMAIL PROTECTED]>
From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: linker problem?
Date: Thu, 13 Jul 2000 17:24:40 GMT
Zoran Cutura <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Peter Huang wrote:
> >
> > Hi
> >
> > I'm trying to build a device driver module on Kernel version 2.2.14-5.0
and
> > I am running into some problems that appears to be linker related.
> >
> > these lines appeared
> >
> > /usr/lib/crt1.o: In function `_start':
[SNIP]
> > It appears that the linker can't find any kernel functions and even
tried to
> > look for the main()
> > function. Can any one give me some suggestion on what might be wrong? On
the
> > testpci.c file itself, I included most of
> > the header files such as <linux/pci.h> <linux/module.h> etc....
> >
> > thanks
> >
> > Peter
>
> seams like you're missing the '-c' option to gcc since
> linking will be done at load time.
>
> Z
If you need to link more than one .obj together, you'll need to invoke the
loader (ld) with the -r option to tell it to do only a partial linking.
When you load the module with insmod, the remainder of the linking against
the kernel-symbols takes place
Norm
------------------------------
From: root <[EMAIL PROTECTED]>
Subject: Re: NFSRoot problems
Crossposted-To: comp.os.linux.development,linux.dev.kernel
Date: Thu, 13 Jul 2000 17:29:18 GMT
I have been unable to find the root on NFS option in the kernel config for 2.2.16. Is
a patch necessary for this, or am I missing something obvious. Do I need to be using
a development kernel?
[EMAIL PROTECTED] wrote:
> In comp.os.linux.development.system Krik Lee <[EMAIL PROTECTED]> wrote:
>> Hi:
>> I am trying NFSRoot in 2.4.0-test2-ac1.
> do you need a 2.4.0-test kernel?
> use a 2.2.x kernel if not
------------------------------
From: Paul Fox <[EMAIL PROTECTED]>
Subject: Re: keyboard with additional function keys
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development,comp.os.linux.hardware
Date: Thu, 13 Jul 2000 17:37:28 GMT
In comp.os.linux.hardware LY <[EMAIL PROTECTED]> wrote:
: I have a keyboard with about 30 additional function keys. If I press one key
have you looked at the man pages for loadkeys, dumpkeys, showkey, and
keytables?
have you looked in /var/log/messages (i think) for reports of unknown
scancodes after using your keyboard?
i was able to load up values for a similar keyboard that i have. (though
mine wasn't producing doubles like yours is -- mine were simply not
understood.)
paul
=---------------------
paul fox, [EMAIL PROTECTED]
------------------------------
** 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 (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
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
******************************
