Linux-Development-Sys Digest #747, Volume #7 Thu, 6 Apr 00 10:13:16 EDT
Contents:
Re: PCI configuration space fun. (Grant Edwards)
Re: PCI configuration space fun. (Grant Edwards)
Re: PCI configuration space fun. (Bryan Hackney)
Re: Random system hangs on Compaq P166/2.2.14 (Bill Hayles)
unresolved symbol ([EMAIL PROTECTED])
Re: unresolved symbol ([EMAIL PROTECTED])
Re: To core or not to core - You tell me ("Joe Schmoe")
Re: Core dumping is halting console (Tim Roberts)
Re: Resetting PCI Bus (Tim Roberts)
Re: FB foolin around (Aki M Laukkanen)
Re: block device development ("Gennadiy M. Kurtsman")
Re: PCI configuration space fun. (Adrian Cox)
Re: PCI configuration space fun. (Adrian Cox)
Re: Flushing Disk Cache ("Paul Goossens")
Re: How compatible is Linux with .. Linux (Nick Andrew)
PCI ADSL Modem Drivers ("Pau Artigas")
Re: To core or not to core - Part 2 (Chuck Dillon)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: PCI configuration space fun.
Date: Thu, 06 Apr 2000 04:13:58 GMT
In article <[EMAIL PROTECTED]>, Daniel J. Feren wrote:
>> PCI boards have a set of configuration registers which do _not_
>> appear in normal PCI bus memory or I/O space. That is the PCI
>> "configuration space". The PCI spec defines a set of these
>> registers at addresses 0x00 through 0x3f. Each PCI board has
>> set of these configuration registers. Vendors can use registers
>> above 0x40 for their own purposes. Since these registers are
>> not visible in normal I/O or Memory space, you have to go
>> through various contortions with the PCI bus controller ASIC to
>> read/write them. Motherboards usually provide BIOS routines
>> for this purpose.
>
>So, I'm understanding that with mmap I could write to the registers
>at 0x40 through 0xef. But not just in that range, it would be the
>base memory address of the specific card plus 0x40 ... 0xef.
No. There is no "base address" for the configuration registers. They do
not appear in the PCI memory or I/O space. AFAIK, you have to diddle
registers in the PCI chipset to read or write the the PCI config registers
on the PCI boards. Your motherboard's BIOS usually provides routines to
access the PCI config registers.
>I'd say from what I've heard from this newsgroup, the first 0x00 .. 0xef of
>the memory address of each pci card is the configuration space of that
>device. Correct?
No.
>or Is it the I/O space that contains the configuration space?
Nope, not that either.
>Or is it specfic to my motherboard and only writeable with bios routines?
That's the way I understand it.
If you understand the PCI chipset you can talk to it directly. Linux provides
an interface to these BIOS routines, or Linux will mess with the motherboard
chipset directly if you don't have a 32-bit PCI BIOS or if you tell the
kernel not to use the BIOS.
>Definitively?
That's the way I understand it. There's a Linux PCI mailing list where the
real experts hang out.
>This hardware is not inexpensive.
--
Grant Edwards grante Yow! The PILLSBURY
at DOUGHBOY is CRYING for
visi.com an END to BURT REYNOLDS
movies!!
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: PCI configuration space fun.
Date: Thu, 06 Apr 2000 04:28:14 GMT
In article <[EMAIL PROTECTED]>, Bryan Hackney wrote:
>Grant Edwards wrote:
>>
>[...]
>> Right. The code below is reading the PCI configuration space,
>> and I don't think you can mmap() the PCI configuration
>> registers which are being accessed below.
>
>You can, and the config space is at the base of the address presented
>at config+0x10.
Really? I've got to go back and look at the specs for the last PCI board
for which I did a driver. I would've bet money that the config registers
didn't show up on the bus. If they do, then I owe you an apology.
>After mmaping, the config space is there!
Do you know if the PCI spec requires this, or is just common practice?
>You can, but you don't have to. You can continue to r/w the config
>space from the I/O mechanism provided.
It appears I've been doing things the hard way. (Wouldn't be the first
time.)
--
Grant Edwards grante Yow!
at TAILFINS!!... click...
visi.com
------------------------------
From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Wed, 05 Apr 2000 23:49:37 -0500
Grant Edwards wrote:
>
[...]
> Do you know if the PCI spec requires this, or is just common practice?
>
I don't know if this is a requirement of a PCI device implementation,
but every device I've cared to talk to through a user level process
has been this way. This includes i960RP, TSB12LV21APGF, and PLX PCI9052.
[...]
--
Bryan Hackney / BHC / [EMAIL PROTECTED]
http://www.FreeClassAds.com/
http://bhconsult.com/
http://bhconsult.com/bh/pgp.key
------------------------------
From: Bill Hayles <[EMAIL PROTECTED]>
Crossposted-To: uk.comp.os.linux
Subject: Re: Random system hangs on Compaq P166/2.2.14
Date: Wed, 05 Apr 2000 20:08:47 +0200
Reply-To: [EMAIL PROTECTED]
On 5 Apr 2000 09:54:12 GMT, [EMAIL PROTECTED] (Stephen Marley)
wrote:
>Could there be a problem related to pci irq sharing between the isdn
>card and the nic, or is that solid in linux 2.2.x? Kinda worries me that
>I can't change any PCI irqs on the compaq without changing them all.
All I can say is that my box works fine with no tweaking from me. In
many ways, Compaqs are foreign hardware to me (I usually build my own
but picked this up cheaply secondhand). I just booted from the SuSE 6.3
CD 2 (I'd heard the tales of woe from using Yast2), partitioned and
reformatted the hard disk (except the Compaq diagnostics partition) and
away I went.
>From Benitachell, Alicante, Spain
Bill Hayles
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: unresolved symbol
Date: Thu, 06 Apr 2000 04:48:48 GMT
Hi all,
After compiling a 'hello, world' module according to the Linux Kernel
module prgroamming's guide, I tried "insmod ex1" ( my program named
ex1.c ) then I got the error
./ex1.o: unresolved symbol printk
Pls give me some advice,
Thanks,
Vu
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: unresolved symbol
Date: Thu, 06 Apr 2000 05:20:36 GMT
In article <8ch4vc$mf3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi all,
>
> After compiling a 'hello, world' module according to the Linux Kernel
> module prgroamming's guide, I tried "insmod ex1" ( my program named
> ex1.c ) then I got the error
>
> ./ex1.o: unresolved symbol printk
>
Sorry for my ignorance. I have an typo error : in CONFIG_MODVERSIONS, I
am lack of 'S'. After fixing, it ran well.
Thanks & sorry,
Vu
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Joe Schmoe" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.lang.c++,comp.unix.programmer
Subject: Re: To core or not to core - You tell me
Date: Thu, 06 Apr 2000 05:37:47 GMT
Ha ha! If you were using DOS, you would have just printed the segment
address of the first interrupt routine. If you were in windows you would
get a GPF.
"Harish K Chandraia" <[EMAIL PROTECTED]> wrote in message
news:8cd1d7$vkl$[EMAIL PROTECTED]...
> Hi All,
>
> I hope that somebody can tell me what is going on here. I
> have the following C program
>
> #include <stdio.h>
>
> int main()
> {
> struct def
> {
> int a;
> };
>
> struct def *ptr;
>
> ptr = NULL;
>
> printf("%d\n", ptr->a);
> }
>
>
> From all that you know about programming what do you think should
> happen when I try to compile and execute the above program. I have
executed
> this piece of code on the following four machines(posting about my
> results will follow). I am not trying to be a smart ass here but I am
> only interested in knowing what you people think would happen because
> what I thought would happen didn't happen on two of the four machines.
>
> 1. (samwise)# uname -a
> unix samwise 5.3 1.0 mc68060
>
> 2. # uname -a
> NonStop-UX leonard 4.2MP C51IPM74.puma.0414.01:12 S5000 mips
>
> 3. hercules23> uname -a
> SunOS hercules23 5.5.1 Generic_103640-24 sun4u sparc SUNW,Ultra-60
>
> 4. icarus# uname -a
> SunOS icarus.cc.uic.edu 5.7 Generic_106541-10 sun4u sparc SUNW,
> Ultra-Enterprise
>
>
> Thank you
> Harish
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: Core dumping is halting console
Date: Wed, 05 Apr 2000 23:29:16 -0700
[EMAIL PROTECTED] wrote:
>This is a problem I had with RedHat 6.0 and Mandrake 6.1 distros (not
>tried the other though) with kernels 2.2.5 through 2.2.9... don't know
>what's happening. As soon as a program segfaults, "Segmentation fault"
>appears on the screen and then the console is halted. The
>process won't get killed in any way. Resources are still in use, so I
>guess core dumping was being done.
This is a bug in the Mandrake 6.0 kernel. The fix is to download an
"official" kernel, 2.2.12 or better, and rebuild. Or, upgrade to Mandrake
7.0.
Mandrake 6.1 didn't exhibit this problem. Are you sure you got a new
kernel out of 6.1?
The faulting process gets hung in a wait-for-I/O state just after opening
the core file. You can't kill a process in wait-for-I/O, and you can't
unmount the file system because the file is open. Note that this only
happens if you're logged in as root; the other solution is to log in as a
regular user.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: Tim Roberts <[EMAIL PROTECTED]>
Subject: Re: Resetting PCI Bus
Date: Wed, 05 Apr 2000 23:36:43 -0700
jvirzi <[EMAIL PROTECTED]> wrote:
>
>I understand this may be an ill-posed question, due to differences in
>manufacturer implementations of the PCI bus. I will still ask the
>question:
On the contrary, the PCI bus is very well specified. Implementation
variations are actually rather slight.
>Is there a way to either/both perform a physical reset of the PCI bus
>within Linux, and/or reconfigure all devices including resource
>allocation?
Resource allocation is a BIOS/OS function. The operating system can redo
the address space assignments any time it wants to. Win98 and Win2000 can
do this kind of reallocation on the fly.
--
- Tim Roberts, [EMAIL PROTECTED]
Providenza & Boekelheide, Inc.
------------------------------
From: [EMAIL PROTECTED] (Aki M Laukkanen)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: FB foolin around
Date: 6 Apr 2000 10:11:38 GMT
In article <[EMAIL PROTECTED]>, Stephen wrote:
>Also, I have the fbvesa stuff compiled in. I'd love to be able to query
>the card and see what modes it supports and then set one.
Yes, well see my patch (for 2.3.40 currently but should backport to 2.2
without too much difficulty):
http://www.cs.helsinki.fi/u/amlaukka/vesafb.html
>From the page:
Vesafb is a Linux Framebuffer Device driver for VBE 2.0 compliant
boards. The original version by Gerd Knorr was restricted to
changing modes at boot time. The enhancements by Aki Laukkanen go
around this restriction by delegating the actual details
to a user-space daemon. This daemon, vesafbd, uses the LRMI (Linux
real mode interface) library to execute the real-mode VBE-BIOS
functions.
--
D.
------------------------------
From: "Gennadiy M. Kurtsman" <[EMAIL PROTECTED]>
Subject: Re: block device development
Date: Thu, 6 Apr 2000 14:34:00 +0400
I had such problem not so long ago. Asking help I got answer that ..._xxxxx
is versioning information. You can see it using *ksyms -a* command. I don't
know how to include or exclude it to/from your module, but I guess that if
you recompile Linux kernel you'll get simultaneous versioning state for the
kernel and your module.
Best regards,
Gennadiy.
Fabrizio wrote in message ...
>Now a question: I'm trying the chardev.c module from the book. No problem
>with the compilation, but when I try to insmod the module I've some
>unresolved symbols related to printk_xxxxxx and sprintf_xxxxxx, where xxxxx
>are sume hex numbers.
>
>Hints ? Suggestions ?
>
>Ciao!
>
> Fabrizio Carrai
>e-mail: [EMAIL PROTECTED]
>
>
>"Master of the system" <[EMAIL PROTECTED]> ha scritto nel messaggio
>news:[EMAIL PROTECTED]...
>> Hi everybody,
>>
>> I'm looking for manuals, books, links, tutorials about how to write a
>> block device.
>> "Linux Device Drivers" from O'Reilly seems not to be very up to date
>> (The book is centered on version 2.0, but also covers 1.2.13 and
>> experimental versions up to 2.1.43.)
>> I wanna program for the next kernel 2.4 so work with 2.39.
>>
>> Can anybody help?
>>
>> Thanks in advance
>>
>> Andreas Fleuti
>>
>>
>> e_mail: afleutiATiiic.ethz.ch (simply replace AT by @ [to prevent spam])
>
>
------------------------------
From: Adrian Cox <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Thu, 06 Apr 2000 12:11:48 +0100
Reply-To: Adrian Cox <[EMAIL PROTECTED]>
Bryan Hackney wrote:
[...]
> Grant Edwards wrote:
> [...]
> > Right. The code below is reading the PCI configuration space,
> > and I don't think you can mmap() the PCI configuration
> > registers which are being accessed below.
> You can, and the config space is at the base of the address presented
> at config+0x10. After mmaping, the config space is there!
On your board, maybe. That is *not* generic advice. Most devices do not
mirror the configuration registers in base address 0. Our own PLX
9080/9054 designs do not do this.
The hardware implementation of configuration space is a completely
different addressing mechanism to memory space or IO space. In
particular, as nobody has yet mentioned, configuration space is
geographical. A configuration address contains components for bus
number, slot number, function number, and register offset.
If you could mmap configuration space, it would still be a really bad
idea. Attempting to read an empty slot and getting an error is a well
defined, and quite normal, occurence. Handling it by catching a SIGBUS
would be a lot more effort than checking a return value.
Look at the pciutils package by Martin Mares:
http://www.freshmeat.net/appindex/1998/04/20/893094449.html
That contains code to read and write PCI configuration from userspace,
in the most generic way possible.
- Adrian Cox, AG Electronics
------------------------------
From: Adrian Cox <[EMAIL PROTECTED]>
Subject: Re: PCI configuration space fun.
Date: Thu, 06 Apr 2000 12:54:24 +0100
Reply-To: Adrian Cox <[EMAIL PROTECTED]>
Grant Edwards wrote:
> In article <[EMAIL PROTECTED]>, Bryan Hackney wrote:
> >Grant Edwards wrote:
> >[...]
> >> Right. The code below is reading the PCI configuration space,
> >> and I don't think you can mmap() the PCI configuration
> >> registers which are being accessed below.
> >You can, and the config space is at the base of the address presented
> >at config+0x10.
> Really? I've got to go back and look at the specs for the last PCI board
> for which I did a driver. I would've bet money that the config registers
> didn't show up on the bus. If they do, then I owe you an apology.
Here's an example of a device in which PCI configuration registers do
not appear in PCI memory space. Consider the PLX9054:
http://www.plxtech.com/products/9054/previews/9054.htm
In this chip configuration space offset 0x10 contains the register
PCIBAR0. This register is set at boot time by the PCI BIOS to contain
PCI Base Address 0 (the PCI memory address of PLX region 0). PLX region
0 contains the "Local Configuration Registers", which are not the same
as the PCI Configuration Registers. Offset 0x10 from the base of region
0 contains register EROMRR, the "Expansion ROM Range Register".
The PCI Configuration Registers are part of the PCI spec, and the Local
Configuration Registers are device specific. (Unless it's an I2O device,
when some of them are standardised as well.) In fact, I2O compliance
can only be achieved if the PCI Configuration Registers are not mirrored
at PCI Base Address 0.
- Adrian Cox, AG Electronics
------------------------------
From: "Paul Goossens" <[EMAIL PROTECTED]>
Subject: Re: Flushing Disk Cache
Date: Thu, 6 Apr 2000 15:20:18 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
jvirzi heeft geschreven in bericht <[EMAIL PROTECTED]>...
>I'm developing some device drivers under Linux for custom hardware
>I've built. In doing so, I inevitably crash the system, or at least
>wreak havoc on some of the internals. I've noticed that when I have
>restarted the machine, some of the files I saved under a previous
>session were never actually written out to the disk. I'm assuming
>there is a disk cache or similar function that gets updated to the
>physical device upon unmounting.
>
>Is there a way to cause the update to occur without un/remounting
>the disk? This way I'm one step closer to preserving my work in the
>event of a system crash.
use the command "sync"
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
iQA/AwUBOOyBAl9XwgRUBUQfEQK1CwCffskpavgqYCz7FBNx2uobkyXZ/d8AoJrb
D2nDFaRUVNmoLGuGp3rRdEk4
=JL9G
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Nick Andrew)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: How compatible is Linux with .. Linux
Date: 6 Apr 2000 23:26:32 +1000
In <7zTG4.14489$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Christopher
Browne) writes:
>Indeed. Now, while MVS offers "generational backup," known as GDGs,
>it is more likely that the system that was being suggested was VMS.
MVS' GDGs are not backups, merely previously written files. A GDG is
basically a filespace recycling mechanism. Because MVS does not manage
storage in a way which people such as myself consider essential it
is often necessary to overwrite existing files rather than simply
create new ones.
A GDG set, e.g. a.b.c(0) a.b.c(-1) a.b.c(-2) etc is just a shorthand
convention for a.b.c.g0005m00 a.b.c.g0004m00 a.b.c.g0003m00 (or
something like that). The service the OS is providing is essentially
expansion of a "relative" filename when referencing files using the
shorthand, and automatic renaming of the oldest file in the set when
using the "+1" shorthand.
It's cute and very handy for keeping a few previous versions of
files which get completely overwritten. One danger though is that
if processing fails for some reason after the oldest member is
renamed, it is necessary to cycle the group backwards in order to
recover. The alternative is to explicitly cycle the group forwards
before starting to write the new file (but then again, if processing
fails, it's necessary to remember to _not_ cycle again before
retry).
I personally don't think this feature is useful enough to add new
Unix filesystem semantics :-)
Nick.
--
Pacific Internet SP4 Fax: +61-2-9233-6545 Voice: 9253-5762
G.P.O. Box 3400, Sydney NSW 1043 http://www.zeta.org.au/
------------------------------
From: "Pau Artigas" <[EMAIL PROTECTED]>
Subject: PCI ADSL Modem Drivers
Date: Thu, 6 Apr 2000 15:45:07 +0200
Hi,
as a linux newbie when i bought an adsl modem i bought it internal and when
i tried using it in linux ... Then i tried to find the drivers, and the most
similar thing i found was a driver for the series of modems but for NetBSD
(in http://www.infolaunch.com/ATM). I would thank anyone giving me some info
about porting it to RedHat 6.1 (if it is possible or necessary) or any info
about what can i do.
Thanks,
Pau Artigas
PD: I mailed the author of them, but i prefer asking here also.
------------------------------
From: Chuck Dillon <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,comp.unix.solaris,comp.unix.questions,comp.unix.programmer
Subject: Re: To core or not to core - Part 2
Date: Thu, 06 Apr 2000 09:01:49 -0500
Mark Langsdorf wrote:
>
> ...
>
> Why aren't you checking pointer values that are being passed to
> you? Bad coding practice.
Not necessarily. I agree that use of some asserts while debugging
would be appropriate but for production code I don't agree that all
functions passed pointers should use CPU time to verify that the
calling code was properly designed and debugged. If you accept
that then you must also accept the notion that ALL arguments should
be validated by all functions at all levels at all times. You would
also have to write wrappers ot check the arguments to all the
system/library functions that don't follow this practice. That's a
lot of wasted cycles to compensate for inadequate testing.
It's good coding practice for a function to do what its documentation
says it does when it is passed valid data and have undefined behavior
when passed garbage. The ideal would be that garbage results in a
core dump but we don't live in an ideal world.
-- ced
--
Chuck Dillon
Senior Software Engineer
Genetics Computer Group, a subsidiary of Oxford Molecular
------------------------------
** 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
******************************
