Linux-Development-Sys Digest #735, Volume #8 Sat, 19 May 01 16:13:09 EDT
Contents:
Re: Reinitializing PCI bus on x86 ("D. Stimits")
Re: Behavior of read() w.r.t.memory protection ("Arthur H. Gold")
mnttab (Rahul)
PID and fork() (Alessandro "oVeRRiDe")
Re: PID and fork() (Pachinko Lin)
Re: PID and fork() ("override")
Re: PID and fork() ("Karl Heyes")
Re: mnttab ("Karl Heyes")
Re: PID and fork() (manik roy)
I could use some help with my X config ("Larry Kuehner")
Re: Sharing the virtual address space? (At150bogomips)
Re: PID and fork()
Re: [kernel] capturing packets ([EMAIL PROTECTED])
Re: I could use some help with my X config (Leonard Evens)
Re: I could use some help with my X config (Dave Uhring)
8259 ISR bits getting stuck set
----------------------------------------------------------------------------
Date: Fri, 18 May 2001 22:24:47 -0600
From: "D. Stimits" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Reinitializing PCI bus on x86
[EMAIL PROTECTED] wrote:
>
> For a semi-embedded project I am working on, it would be really nice
> if the memory ranges assigned to PCI cards would be below 0xc0000000.
> That would allow me to mmap() them into a process's address space
> with a 1:1 mapping (which is required, as this process is an emulator,
> and the emulated machine's memory is supposed to map 1:1 on the
> process's, and *it* is supposed to look at the PCI config space
> for addresses).
>
> However, from my kernel readings, it appears that the PCI bus is set
> up by the BIOS on the x86 platform, and that linux simply uses the
> address ranges supplied by the bios.
> Is there a way to force a re-initialization at boot time (preferably
> *before* starting any device drivers :). And if so, is there a way to
> force those address ranges below 0xc0000000?
>
> I don't mind if it involves patching the kernel itself; The kernel I am
> using is already pretty badly patched to provide some extra functionality.
> However, I am a bit reluctant to simply insert something like the following
> at the start of the kernel's PCI handling:
>
> maxad=0
> for (c over all cards)
> for (a over all membases on card c)
> maxad=max(maxad,a+len(a))
> for (c over all cards)
> for (a over all membases on card c)
> membase(a)-=maxad-0xb0000000
>
> It probably would do the job, but still....
I don't know if this would help, but you might take a look at the source
from "setpci" (cousin to lspci), which is able to manipulate parts of
PCI setup. If setpci can manipulate what you want, then you can probably
use very similar code.
D. Stimits, [EMAIL PROTECTED]
>
> Bernie
> --
> Older man declare war. But it is youth who must fight and die
> Herbert Hoover
> US President 1929-33
> At the Republican National Convention, 27 June 1944
------------------------------
Date: Fri, 18 May 2001 22:03:00 -0500
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: Behavior of read() w.r.t.memory protection
John Reiser wrote:
>
> > > > Run in linux, it behaves as follows:
> > > > pbuf = 40014ffc, read() returned 4
> > > > pbuf = 40014ffb, read() returned 4
> > > > pbuf = 40014ffa, read() returned 4
> > > > pbuf = 40014ff9, read() returned 4
> > > > pbuf = 40014ff8, read() returned 8
> > > > pbuf = 40014ff7, read() returned 8
> > It is these cases that I find interesting (and to which you have have
> > not responded).
>
> I'll repeat, using different words: Linux is an "eager beaver",
> and finds a way to succeed partially, as if by "truncating" the buffer.
> Due to vagaries of x86 protection, speed, and programming convenience,
> Linux does this on the basis of aligned, 4-byte units. FreeBSD
> chooses to be diffident, quibbling that part of the buffer is
> off limits, and says, 'No, I won't," even though the start of the
> buffer is valid and data is available. You could say that FreeBSD
> does the _same_ as Linux, except with buffer-length units
> instead of aligned 4-byte units.
Well, actually just 4-byte units, but that's a quibble.
>
> > But when the number of bytes read is limited by protections on
> > _part_ of the buffer, you're non the wiser.
>
> On the contrary, you can tell that the number of bytes read is less
> than the third argument; in some sense, a "short read". A sufficiently-
> motivated program[mer] will use that information to deduce that an
> interesting case has arisen.
>
> > At least the FreeBSD
> > behavior lets you know that something `out of the ordinary' has happened
> > (i.e. that you're tried to read into protected space).
>
> Linux does let you know: the return value is less than the
> third argument to read(). This is a clue. If the next read
> is into the same buffer at the next adjacent byte, then
> the return value will be -1 with EFAULT, the same as FreeBSD.
> If the next read is into the same buffer at the beginning,
> then once again Linux will successfully read a few bytes.
> The EFAULT on Linux is "out of phase" with FreeBSD
> by "half a cycle," but during that half cycle Linux delivers
> good bytes into the good part of the buffer.
OK. I can see that.
>
> So, Linux chooses to make progress whenever it can, and FreeBSD
> chooses to be as strict as possible. I consider both choices
> to be consistent with the interface contract, and my programs
> work the way I want on both systems with no conditional compilation
> or runtime querying of OS type. (And I wrote the code that way
> in the first place, before either FreeBSD or Linux existed.)
>
Of course, you most likely weren't using `stupid memory protection
tricks' (I admit, it's an unusual situation).
Thanks for your thorough explanation!
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
I am looking for work. Contact me.
------------------------------
From: [EMAIL PROTECTED] (Rahul)
Subject: mnttab
Date: 18 May 2001 23:25:33 -0700
Hi,
I am working in C on Linux. I had a query about the accesing the
superblock on Linux. I know this could be done on Unix using the the
mntab and the filsys structures, but I was not able to find the mntab
structure. I came to know that the filsys has a correspoing structure
super_block in the linux/fs.h. I tried to use this strucutre but the
gcc could not find this stucture.
Plz help. Thanx in advance.
Regards,
Rahul.
------------------------------
From: Alessandro "oVeRRiDe" <[EMAIL PROTECTED]>
Subject: PID and fork()
Date: Sat, 19 May 2001 08:32:20 GMT
If i do:
pid=fork();
in pid i get the value 0 if the child process was created correctly, -1
otherwise. That's rigth, 'cos those are the two values returned in child's
thread of execution but... how do i get child's PID? Man says thaty it is
returned in parent's thread of execution (???)... help please!
------------------------------
From: Pachinko Lin <[EMAIL PROTECTED]>
Subject: Re: PID and fork()
Date: Sat, 19 May 2001 08:44:54 +0000 (UTC)
Alessandro oVeRRiDe <[EMAIL PROTECTED]> wrote:
> If i do:
> pid=fork();
> in pid i get the value 0 if the child process was created correctly, -1
> otherwise. That's rigth, 'cos those are the two values returned in child's
> thread of execution but... how do i get child's PID? Man says thaty it is
> returned in parent's thread of execution (???)... help please!
The following sentences comes from fork(2).
On success, the PID of the child process is returned in
the parent's thread of execution, and a 0 is returned in
the child's thread of execution. On failure, a -1 will be
returned in the parent's context, no child process will be
created, and errno will be set appropriately.
What you want is the return value of fork() in the parent's thread.
------------------------------
From: "override" <[EMAIL PROTECTED]>
Subject: Re: PID and fork()
Date: Sat, 19 May 2001 11:33:38 GMT
Ok but...
pid=fork();
printf("%d", pid);
if (pid==0)
{
execve(mycommand, argv, env);
}
else
{
wait(??) //what should i put inside? any number is ok?
}
prints 0 on the screen and execs the child. Well, child's pid is
not zero, in fact, using ps:
myshell 6740
ps 6741
so ps was loaded by myshell's child, and the pid is 6741, not 0...
All this because i'd be able to execute programs in background
(someone told me that i have to use waitpid(), with child's pid as
parameter...
Thanks for your answer
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: PID and fork()
Date: Sat, 19 May 2001 13:49:38 +0100
In article <ocqN6.4260$[EMAIL PROTECTED]>, "Alessandro oVeRRiDe"
<[EMAIL PROTECTED]> wrote:
> If i do:
> pid=fork();
> in pid i get the value 0 if the child process was created correctly, -1
> otherwise. That's rigth, 'cos those are the two values returned in child's
> thread of execution but... how do i get child's PID? Man says thaty it is
> returned in parent's thread of execution (???)... help please!
fork is creating another instance of the same program. As you said the
-1 code is returned when the extra instance cannot be created. In each
instance the fork will return but with different values. 0 to the child
instance (getppid can get the parents pid in that case), and a >0 number
which is returned to the parent instance, indicating the pid of the child
that has been created.
This is a standard POSIX thing.
karl.
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: mnttab
Date: Sat, 19 May 2001 14:06:16 +0100
In article <[EMAIL PROTECTED]>, "Rahul"
<[EMAIL PROTECTED]> wrote:
> Hi,
> I am working in C on Linux. I had a query about the accesing the
> superblock on Linux. I know this could be done on Unix using the the mntab
> and the filsys structures, but I was not able to find the mntab structure.
> I came to know that the filsys has a correspoing structure super_block in
> the linux/fs.h. I tried to use this strucutre but the gcc could not find
> this stucture.
> Plz help. Thanx in advance.
> Regards,
> Rahul.
This depends on what you want to do. In a general filesystem independent
lookup of a mounted filesystem use statfs/fstatfs.
As for accessing mtab or mnttab can you use getmntent calls. gcc probably
couldn't see the structure as the define __KERNEL__ wasn't set, but be
careful what you modiify if that is your intention.
karl.
------------------------------
From: [EMAIL PROTECTED] (manik roy)
Subject: Re: PID and fork()
Date: 19 May 2001 06:35:20 -0700
Pachinko Lin <[EMAIL PROTECTED]> wrote
> What you want is the return value of fork() in the parent's thread.
Exactly.
pid_t ch_pid;
ch_pid = fork();
if(ch_pid == 0 ){
/* chlid code here */
}else if (ch_pid > 0 ){
/*Parent code here*/
printf("child pid %d\n", ch_pid);
} else perror("fork\n");
================|
[EMAIL PROTECTED] |
================|
------------------------------
From: "Larry Kuehner" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.help,comp.os.linux.questions,comp.os.linux.setup,comp.os.linux.X
Subject: I could use some help with my X config
Date: Sat, 19 May 2001 10:45:52 -0700
Hi, I am having problems configuring my mouse to work in XFree. I am running
Debian on a Dell Inspirion 7500. I used to be able to get my touch pad to
work, but now it will not. I have even set everything the same as it was
when it worked. The problem might be the Mach64 server I had to get all set
up to get the display to work at higher resolutions. I got the display off
of the Linux Laptop page. I am trying to get either my touch pad, or my
Microsoft Intellimouse Explorer to work. Any help will be appreciated.
Thank you,
Larry Kuehner
------------------------------
From: [EMAIL PROTECTED] (At150bogomips)
Date: 19 May 2001 15:56:12 GMT
Subject: Re: Sharing the virtual address space?
Josef Moellers <[EMAIL PROTECTED]> wrote:
>This is called "shared memory".
>Also, applications executing the same code share the same virtual
>address space of the code.
I thought shared memory 'merely' shared the mapping for each code page. I.e.
different programs use address space 0x00..00 and following.
I am referring to having a single page table. This would in theory allow all
code to be a common library--accessible to any program.
Paul A. Clayton
just a fool, not in love
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: PID and fork()
Date: Sat, 19 May 2001 16:14:49 -0000
In article <ocqN6.4260$[EMAIL PROTECTED]>,
Alessandro "oVeRRiDe" <[EMAIL PROTECTED]> wrote:
>If i do:
>pid=fork();
>in pid i get the value 0 if the child process was created correctly, -1
>otherwise.
No, if you get a value of 0, you *are* the child process. Otherwise you
get the PID (or -1 for error).
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: [kernel] capturing packets
Date: Sat, 19 May 2001 17:53:35 GMT
On Mon, 14 May 2001 11:12:54 +0400, Vyacheslav Burdjanadze
<[EMAIL PROTECTED]> wrote:
If you are using kernel 2.4.x you can use the netfilter architecture.
Just write a module and register it with netfilter. Shouldn't be too
hard. See
http://antarctica.penguincomputing.com/~netfilter/
for all the information.
>Hello.
>
>Just wondering if following is possible:
>I want to grab *outcoming* IP packet on specified interface and taking
>some action on it.
>Then I need to replace original packet with my data and let the
>underlying system to pass packet his way. This is required to
>transparent encrypting of IP packets. What mechanism exists in Linux
>kernel
>to do this? I read about netlink socket interface but it doesn't seem to
>help me. :(
------------------------------
From: Leonard Evens <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.help,comp.os.linux.questions,comp.os.linux.setup,comp.os.linux.X
Subject: Re: I could use some help with my X config
Date: Sat, 19 May 2001 13:03:03 -0500
Larry Kuehner wrote:
>
> Hi, I am having problems configuring my mouse to work in XFree. I am running
> Debian on a Dell Inspirion 7500. I used to be able to get my touch pad to
> work, but now it will not. I have even set everything the same as it was
> when it worked. The problem might be the Mach64 server I had to get all set
> up to get the display to work at higher resolutions. I got the display off
> of the Linux Laptop page. I am trying to get either my touch pad, or my
> Microsoft Intellimouse Explorer to work. Any help will be appreciated.
>
> Thank you,
> Larry Kuehner
Which kernel are you running? Also, what exactly are the
symptoms you see when configuring X. On my Winbook XL, under RH7.1
with 2.4.2 kernel, there is an interrupt conflict between the
pcmcia controller and the PS/2 mouse, which is a bit subtle.
It arose only under the 2.4 kernels. I have a workaround.
--
Leonard Evens [EMAIL PROTECTED] 847-491-5537
Dept. of Mathematics, Northwestern Univ., Evanston, IL 60208
------------------------------
From: Dave Uhring <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.help,comp.os.linux.questions,comp.os.linux.setup,comp.os.linux.X
Subject: Re: I could use some help with my X config
Date: Sat, 19 May 2001 13:44:25 -0500
Larry Kuehner wrote:
> Hi, I am having problems configuring my mouse to work in XFree. I am
> running Debian on a Dell Inspirion 7500. I used to be able to get my touch
> pad to work, but now it will not. I have even set everything the same as
> it was when it worked. The problem might be the Mach64 server I had to get
> all set up to get the display to work at higher resolutions. I got the
> display off of the Linux Laptop page. I am trying to get either my touch
> pad, or my Microsoft Intellimouse Explorer to work. Any help will be
> appreciated.
>
> Thank you,
> Larry Kuehner
For XFree86-4
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/psaux"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "no"
EndSection
For XFree86-3
Section "Pointer"
Protocol "IMPS/2"
Device "/dev/psaux"
# For wheel support - can not be used with Emulate3Buttons
#
ZAxisMapping 4 5
# When using XQUEUE, comment out the above two lines, and uncomment
# the following line.
# Protocol "Xqueue"
# Baudrate and SampleRate are only for some Logitech mice
# BaudRate 9600
# SampleRate 150
# Emulate3Buttons is an option for 2-button Microsoft mice
# Emulate3Timeout is the timeout in milliseconds (default is 50ms)
# Emulate3Buttons
# Emulate3Timeout 50
# ChordMiddle is an option for some 3-button Logitech mice
# ChordMiddle
EndSection
Don't know about touchpads. Mice I do know.
Above configs "ASSUME" connection to PS/2 port, YMMV.
------------------------------
From: <[EMAIL PROTECTED]>
Subject: 8259 ISR bits getting stuck set
Date: Sat, 19 May 2001 19:57:21 GMT
This is a long one. I apologize in advance.
Under extremely heavy interrupt load, we see that the machine eventually
'locks up'. The serial console show the ide driver complaining about
'lost interrupts' every few seconds as the driver expiry timer is
called. The console is very unresponsive processing 16 bytes of
text every few seconds as probably some timer expiry event clearing out
the UART. Investigation shows that only IRQ 0 (timer) and IRQ 1 (keyboard)
are still incrementing in /proc/interrupts.
We added code to the kernel idle task to periodically print out
the stat of various 8259 interrupt controller registers. Under
normal operation, the in-service-register (ISR) is always 0x00
indicating no interrupt is currently being processed and
the interrupt-request-register (IRR) is always 0x00 showing that
there are no pending interrupts. This seems correct as we
wouldn't be in the idle task if there were interrupts to be
serviced.
However, after the 'lock up', the 8259 always reports that one
interrupt in the ISR ( typically one of the IDE or ethernet
interrupts with its correspinding IRQ 2 cascade IRQ ) is
permanently set. This appears to be blocking all futher
interrupts of lower priority leaving only IRQ 0 and IRQ 1
free to fire.
We've tried adding code to the idle task that checks the
8259 ISR registers and then sends the specific EOIs if any
ISR bits are set. This works sometimes in bringing the
machine back to life but sometimes causes a very hard
lock were not even the idle task is executing.
Reading the linux 2.2.18 interrupt code, it appears that
if the CPU ever responds to an interrupt, do_IRQ() is
called and the corresponding mask_and_ack() which
resets the ISR with a specific EOI will always be called even
before the specific interrupt handler code is executed.
In addition, tests reading the ISR after sending the EOI in
mask_and_ack() always report that the EOI was succusfull in
resetting the ISR bit. Also, other tests indicate that
it is never the case that an interrupt service routine
is entered but not exited.
This leads us to believe that the only way for this condition
to occur is if the CPU has sent at least the first INTA
interrupt acknowledge telling the 8259s to select
the highest priority interrupt to send and to freeze the corresponding
ISR bits and:
1) the 8259 never recieves the second INTA telling it to place the IRQ
vector on the bus or
2) it does recieve the INTA but the CPU never recieves the IRQ vector
off the bus.
These two cases would leave the ISR bits set as no interrupt service
routine would ever be called resulting in an EOI being sent.
My questionn ( finally :) is how is the possible.
Is this possibly due to the convoluted path that interrupt
signals and vectors must take across the PCI bus and
the host-pci buss? For example, the South Bridge actually
is responsible for faking out the 8259 by sending the two
INTAs that it is expecting from the CPU. Similarly, the
North Bridge 'pretends' to be the 8259 with respect to the
CPU.
Somehow is DMA causing our interrupt vector to get lost or discarded?
This is an embedded linux box and changing the hardware or
kernel is for all practical purposes not possible.
Locks up in under ten minutes when:
* Heavy load on UDMA 100 High-Point HPT370 controller.
* Does not lock up in PIO mode.
* Heavy ethernet load not necessary but greatly hastens
a 'lock up'.
The VIA ide controller on the South Bridge does not cause
any problems under the same testing.
We've used 2.4 kernel quirk_vialatency patch but it doesn't
seem to help. We've played with changing the PCI latency
values with no significant effect either.
Odly enough, Windows 2000 does not experience this problem
on the exact same hardware. We've examined the PCI register
space on Win2K using WPCREDIT to see if it changes any
chip-set registers in an interesting way. The minimal
difference don't seem to help us.
Specifics:
Kernel 2.2.18 with Hendirck's ide.2.2.18.12XX.patch
North Bridge: VIA VT82C694X | Apollo Pro 133A
South Bridge: VIA VT8321 /
* on-chip VIA ide controller ( via82cxx driver )
* on-chip fast ethernet controller ( via-rhine driver )
* 8259 compatable interrupt controllers
High-Point HTP370 ide controller on motherboard ( hpt3xx driver )
CPU: Celeron 566
Thanks in advacne for help.
--
"Outside of a dog, a book is a man's best friend. Inside of a dog,
it's too dark to read." --Groucho Marx
------------------------------
** 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
******************************
