Linux-Development-Sys Digest #758, Volume #8 Tue, 29 May 01 18:13:12 EDT
Contents:
cache profiler (Marco Lazzaroni)
Re: linux smp/RT development question. (khz)
Re: mtrr: type mismatch (Heinz Ruffieux)
Anyone have problem with dump 0.4b22 going on forever? (Anonymous)
Re: gcc 2.95, segfault when throwing exceptions (_eh_rtime_match) ("Dirk-Jan C.
Binnema")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Marco Lazzaroni)
Subject: cache profiler
Date: Tue, 29 May 2001 20:25:44 +0000 (UTC)
hello there
where can I get a profiler like gprof, but with cache information (i.e.
cache misses) ?
Thanks,
Marco Lazzaroni
--
Posted from smtp3.libero.it [193.70.192.53]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: khz <[EMAIL PROTECTED]>
Subject: Re: linux smp/RT development question.
Date: Tue, 29 May 2001 23:12:31 +0200
the use of shared memory for inter-process-communication
is, to me, the chosen one for my processes ( on one system ).
to get over the linux system call (which could make my process a non-rt-process)
i could use the clone call with sharing memory flag
to access memory within two processes without changing to kernel mode (i think).
to portabillity issues i could say that i plan to change the less possible on the
linux kernel.
the rt-process should only communicate (shared memory) and do i/o on the parallel
port
(just for testing purposes). it's planed to go from parallel to some fast network
connection
or bus system.
but as said i think it's much harder to implement drivers from scratch for rtlinux
than to alter one of the numerous existing ones for linux. and if it's just adding
a new driver and syscall,
derived from existing ones, and not changing existing syscalls it should be 'easy'
to port since
it is just the one syscall.
my rt processes should definetly not use all possible i/o or communication
methods.
--- dream ---
the change to fast network or bus communication should lead to a (over this bus)
conected
cluster consisting of several smp machines with n cpu's. running one rt process
as a memory manager on every system. this would establish a pc based smp cluster
system
with a distributed memory architecture. where every machine should be able to
access any ram-memory
location in the cluster as if it was the ram of the machine. an addition could be
to have the opportunity
to fork a new rt process doing other stuff (my test example will be parallel port
i/o)
if there's a free cpu anywhere in the cluster. this shall work like pvm but rt,
more transparent
and with a distributed memory.
--- dream ---
as a start i would like to know if it's possible to alter do_fork and schedule to
make
one speciall process run on one (by the process chosen) cpu (all alone)
in a standard linux smp system.
so i think the changes to schedule would include to disable one runqueue if the
process started.
the changes in do fork would e.g. look for a flag to identify it as this special
process
and by setting the interrupt bitmask of the apic of the cpu to block all incoming
interrupts
i think it should run forever on this cpu since no kernel routine is ever started
on it.
and since in pc-smp-systems every cpu can access every memory location i should
still
be able to communicate with another (standard) process which is sharing memory
(via clone_call).
-- could anybody tell me if i'm rigth till here ? or if there coould be problems
since the two processes
-- would be still related via pids (since they are clones) and if this could make
this scenario
-- break up ?
if this scenario would work , i think that it would be comparable solution to an
RT-Linux system running one
rtprocess with no i/o on one cpu in an smp system and a linux system on the other.
and that would be one step ahead to solve my problem with hard real time on
standard linux.
and on the other hand it would make rt-behaviour between such a solution and one
using
rtlinux more comparable.
any comments appreciated,
klaas
bill davidsen wrote:
>
>
> As long as you realize that some system calls do not produce
> deterministic clock time delays. You probably would be getting more
> result for less effort if you ran your RT process and had it use a
> standard Linux process to do the possibly slow things. Shared memory
> comes to mind as one possible way to do this, depending on data rate.
>
> It also means you will have great portability, instead of maintaining
> your own patches of the kernel into the future.
>
> Note that if you use non-RT system services, you may need them faster
> than the kernel can provide them, and your RT process will either block
> and stop being RT, or it must gracefully cope with unavailable services.
> I'm sure you know this, but it's worth saying as a discussion point.
>
> --
> 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: Heinz Ruffieux <[EMAIL PROTECTED]>
Subject: Re: mtrr: type mismatch
Date: Tue, 29 May 2001 21:30:08 -0000
Here is the output of lspci -vv: (unfortunately I can not get the output in
a better format)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133]
(rev
02)
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-
Latency: 0
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA+ AGP+ 64bit- FW- Rate=x2
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
(prog-if 00 [Normal decode])
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-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d8000000-dbffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South]
(rev 40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
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-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP])
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-
Latency: 32
Region 4: I/O ports at d000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if
00 [UHCI])
Subsystem: Unknown device 0925:1234
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-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at d400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) (prog-if
00 [UHCI])
Subsystem: Unknown device 0925:1234
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-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at d800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
(rev 40)
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 ? routed to IRQ 11
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio
Controller (rev 50)
Subsystem: Micro-star International Co Ltd: Unknown device 3400
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 C routed to IRQ 5
Region 0: I/O ports at dc00 [size=256]
Region 1: I/O ports at e000 [size=4]
Region 2: I/O ports at e400 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:09.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller
(rev 43)
Subsystem: D-Link System Inc: Unknown device 1400
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-
Latency: 32 (750ns min, 2000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at ec00 [size=256]
Region 1: Memory at df000000 (32-bit, non-prefetchable)
[size=256]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF
(prog-if 00 [VGA])
Subsystem: ATI Technologies Inc: Unknown device 0008
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-
Latency: 32 (2000ns min), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
Region 1: I/O ports at c000 [size=256]
Region 2: Memory at dd000000 (32-bit, non-prefetchable)
[size=16K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [50] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x2
Capabilities: [5c] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
I do not understand one word of this :-)
Thanks a lot
Heinz
=?iso-8859-1?Q?Andr=E9?= David wrote:
>
> This is a multi-part message in MIME format.
> --------------959B12AAE8C383F2510F3194
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Heinz Ruffieux wrote:
> >
> > Andre,
> >
> > [ruffieux@locarno ruffieux]$ cat /proc/mtrr
> > reg00: base=0x00000000 ( 0MB), size=16711936MB: write-back, count=1
> > reg05: base=0xd0000000 (3328MB), size=16711808MB: write-combining,
count=1
> > [ruffieux@locarno ruffieux]$
> >
> > I'm have an AMD Duron 850 MHz processor, Micro ATX VA (MS6340)
Mainboard.
> > What specifiction do you need in terms of pci?
>
> As root run lspci -vv and post the result ... sorry to have taken so
> long.
>
> I want to know which device is mapped to address 0xd8000000. Anyway the
> size fields in your MTRR configuration is strange, right ?
>
>
> >
> > Hope this is helpfull.
> >
> > Thanks a lot
> >
> > Heinz
> >
> > =?iso-8859-1?Q?Andr=E9?= David wrote:
> > >
> > > This is a multi-part message in MIME format.
> > > --------------5706AE751E1AB98BEBA3682D
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Transfer-Encoding: 7bit
> > >
> > > Heinz Ruffieux wrote:
> > > >
> > > > Hi,
> > > >
> > > > Booting the kernel (RH7.1 / Kernel 2.4.2.) I get the following
message
> > in
> > > > the /var/log/messages file:
> > > >
> > > > May 25 10:19:32 locarno kernel: mtrr: type mismatch for
> > d8000000,1000000
> > > > old: write-back new: write-combining
> > > >
> > > > Does anybody know what it is about? Is it related with my CD
writer?
> > Can
> > > > somebody tell me what the message means?
> > > >
> > > > Thanks a lot
> > > >
> > > > Heinz
> > > >
> > > > --
> > > > Posted via CNET Help.com
> > > > http://www.help.com/
> > >
> > > Please provide the output of
> > >
> > > cat /proc/mtrr
> > > lspci -vv
> > >
> > > AFAI can say, your BIOS is declaring some PCI memory area as
write-back,
> > > and linux doesn't feel that's safe. What motherboard/processor/pci
> > > boards combination you have?
>
> --
>
> "Share the code. If you hide it ain't good."
> Popular knowledge
> --------------959B12AAE8C383F2510F3194
> Content-Type: text/x-vcard; charset=us-ascii;
> name="Andre.David.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Andr� David
> Content-Disposition: attachment;
> filename="Andre.David.vcf"
>
> REMOVED INCLUDED FILE:vcard
>
> --------------959B12AAE8C383F2510F3194--
>
--
Posted via CNET Help.com
http://www.help.com/
------------------------------
Date: Tue, 29 May 2001 17:58:19 -0400
Subject: Anyone have problem with dump 0.4b22 going on forever?
From: Anonymous <[EMAIL PROTECTED]>
I have this backup script, which used to
work fine before. Now dump keeps going
forever until it runs out of space.
Note the filesystem is only about 280,000 blocks.
But dump keeps going forever.
Anyone encounter this error and find a solution?
+ sh -c '/auto/sw/dump/0.4b22/sbin/dump -T "Wed Dec 31 19:00:00 1969" -B 1500000 -M -f
+/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump
+ /'
DUMP: Date of this level 0 dump: Tue May 29 16:59:57 2001
DUMP: Dumping /dev/hda1 (/) to
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump001
DUMP: Label: /
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 280848 tape blocks on 0.19 tape(s).
DUMP: Dumping volume 1 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump001
DUMP: Volume 1 started with block 1 at: Tue May 29 16:59:59 2001
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 100.00% done at 2437 kB/s, finished in 0:00
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump001
DUMP: Volume 1 completed at: Tue May 29 17:06:35 2001
DUMP: Volume 1 1500000 tape blocks (1464.84MB)
DUMP: Volume 1 took 0:06:36
DUMP: Volume 1 transfer rate: 3787 kB/s
DUMP: Dumping volume 2 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump002
DUMP: Volume 2 started with block 1500001 at: Tue May 29 17:06:35 2001
DUMP: Volume 2 begins with blocks from inode 83538
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump002
DUMP: Volume 2 completed at: Tue May 29 17:09:45 2001
DUMP: Volume 2 1500000 tape blocks (1464.84MB)
DUMP: Volume 2 took 0:03:10
DUMP: Volume 2 transfer rate: 7894 kB/s
DUMP: Dumping volume 3 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump003
DUMP: Volume 3 started with block 3000001 at: Tue May 29 17:09:45 2001
DUMP: Volume 3 begins with blocks from inode 83538
DUMP: 100.00% done at 7782 kB/s, finished in 0:00
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump003
DUMP: Volume 3 completed at: Tue May 29 17:12:54 2001
DUMP: Volume 3 1500000 tape blocks (1464.84MB)
DUMP: Volume 3 took 0:03:09
DUMP: Volume 3 transfer rate: 7936 kB/s
DUMP: Dumping volume 4 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump004
DUMP: Volume 4 started with block 4500001 at: Tue May 29 17:12:54 2001
DUMP: Volume 4 begins with blocks from inode 83538
DUMP: 100.00% done at 7950 kB/s, finished in 0:00
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump004
DUMP: Volume 4 completed at: Tue May 29 17:16:03 2001
DUMP: Volume 4 1500000 tape blocks (1464.84MB)
DUMP: Volume 4 took 0:03:09
DUMP: Volume 4 transfer rate: 7936 kB/s
DUMP: Dumping volume 5 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump005
DUMP: Volume 5 started with block 6000001 at: Tue May 29 17:16:03 2001
DUMP: Volume 5 begins with blocks from inode 83538
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump005
DUMP: Volume 5 completed at: Tue May 29 17:19:10 2001
DUMP: Volume 5 1500000 tape blocks (1464.84MB)
DUMP: Volume 5 took 0:03:07
DUMP: Volume 5 transfer rate: 8021 kB/s
DUMP: Dumping volume 6 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump006
DUMP: Volume 6 started with block 7500001 at: Tue May 29 17:19:10 2001
DUMP: Volume 6 begins with blocks from inode 83538
DUMP: 100.00% done at 7724 kB/s, finished in 0:00
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump006
DUMP: Volume 6 completed at: Tue May 29 17:22:21 2001
DUMP: Volume 6 1500000 tape blocks (1464.84MB)
DUMP: Volume 6 took 0:03:11
DUMP: Volume 6 transfer rate: 7853 kB/s
DUMP: Dumping volume 7 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump007
DUMP: Volume 7 started with block 9000001 at: Tue May 29 17:22:21 2001
DUMP: Volume 7 begins with blocks from inode 83538
DUMP: 100.00% done at 7933 kB/s, finished in 0:00
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump007
DUMP: Volume 7 completed at: Tue May 29 17:25:30 2001
DUMP: Volume 7 1500000 tape blocks (1464.84MB)
DUMP: Volume 7 took 0:03:09
DUMP: Volume 7 transfer rate: 7936 kB/s
DUMP: Dumping volume 8 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump008
DUMP: Volume 8 started with block 10500001 at: Tue May 29 17:25:30 2001
DUMP: Volume 8 begins with blocks from inode 83538
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump008
DUMP: Volume 8 completed at: Tue May 29 17:28:39 2001
DUMP: Volume 8 1500000 tape blocks (1464.84MB)
DUMP: Volume 8 took 0:03:09
DUMP: Volume 8 transfer rate: 7936 kB/s
.
.
.
DUMP: Dumping volume 203 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump203
DUMP: Volume 203 started with block 12303514 at: Tue May 29 17:29:21 2001
DUMP: Volume 203 begins with blocks from inode 83538
DUMP: End of tape detected
DUMP: Closing
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump203
DUMP: Volume 203 completed at: Tue May 29 17:29:21 2001
DUMP: Volume 203 193 tape blocks (0.19MB)
DUMP: Dumping volume 204 on
/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump204
DUMP: Cannot open output
"/auto/backup-c700-0/dump/time-range/from-1969-12-31/19-00-00--0500/to-2001-05-29/16-59-57--0400/celeron700-2.xxxxxxxxx-pn.com/root.dump204".
DUMP: fopen on /dev/tty fails: No such dev
--------== Posted Anonymously via Newsfeeds.Com ==-------
Featuring the worlds only Anonymous Usenet Server
-----------== http://www.newsfeeds.com ==----------
------------------------------
From: "Dirk-Jan C. Binnema" <[EMAIL PROTECTED]>
Subject: Re: gcc 2.95, segfault when throwing exceptions (_eh_rtime_match)
Date: Wed, 30 May 2001 00:10:39 +0200
Reply-To: [EMAIL PROTECTED]
Thanks for the answer!
In article <[EMAIL PROTECTED]>, "Nix"
<$}xinix{[email protected]> wrote:
>> I've been experimenting a bit with -fnew-exception, -fsjf-exception and
>> -fsjf-no-exception (sp?), but so far, it doesn't seem to work; I might
>> me the case that some other parts of my code may have been compiled
>> with different exception-related flags.
>
> It looks very much like that's true. The various exception handling
> flags are not intercompatible; if you compile part of your program with
> those flags, all of your program *must* be using the same eh scheme, or
> no scheme at all. Definitely, on Linux platforms, the C library must be
> built with the same eh scheme as the program actually uses (because of
> an ugly hack where some of the eh functions get sucked into the C
> library from libgcc2 when the C library is built).
>
> Exception handling tables are a global property of the program, because
> of the need to throw across translation unit boundaries; they can't
> change form within a single process.
Hmmm... does this also apply to the shlib's? I would think so; however,
that'll cause a lot of headache when trying to use multiple binary-only libs which
were compiled with different settings....
>> So - does anybody recognize this problem? What can I do?
>
> I've never seen it, but it's quite obvious what's happening:
<snip: source code>
> Since you're segfaulting in __eh_rtime_match() and not in something it
> calls, you're getting something comprehensible back from
> __get_eh_info(), but it's not an __eh_info structure, and its
> match_function pointer isn't a pointer to a function at all.
Ah, that clears things up; I didn't have the sources handy.
> Something is seriously screwed up. I'd make sure first that everything
> which your program uses is using the same eh scheme; I expect that that
> will fix it.
Hmm... I kept on seeing crashes; some third party (bin only) libs may be the
cause. Doesn't close source suck...
Anyway, I seem to have solved the problem by explicitly linking with
-lgcc before -lstdc++. I can't say I totally understand, though.
Anyway, thanks a lot.
Cheers,
Dirk-Jan.
------------------------------
** 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
******************************
