Linux-Development-Sys Digest #72, Volume #7 Thu, 19 Aug 99 15:14:19 EDT
Contents:
Re: Importance of TX errors? (pcmcia) (Brent R Brian)
Re: linking (-ldl) [egcs-1.1.2] failure ([EMAIL PROTECTED])
Re: most efficient way to zero out a partition? (Doug DeJulio)
Re: Importance of TX errors? (pcmcia) (Etienne Lorrain)
Re: Source code licenses allow sharing between Linux and BSDs? ("Edward Reid")
Re: Talking to floppy and hard drive controllers under Linux ([EMAIL PROTECTED])
Re: Best place in kernel for block encryption ? (=?US-ASCII?Q?=1B$B5uL5=1B?=(B)
Re: Importance of TX errors? (pcmcia) (Allin Cottrell)
Re: Question about segments (Emile van bergen)
Re: most efficient way to zero out a partition? (H. Peter Anvin)
Re: Importance of TX errors? (pcmcia) ("Pat Crean")
Re: Calling a BIOS interrupt (Grant Edwards)
Re: Talking to floppy and hard drive controllers under Linux (R�khar�ur Egilsson)
Re: Why so inefficient source RPM's ?? (Chris Butler)
----------------------------------------------------------------------------
From: Brent R Brian <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Importance of TX errors? (pcmcia)
Date: Thu, 19 Aug 1999 08:48:35 -0400
Have you tried another cable ??
B
=========================
Allin Cottrell wrote:
>
> I have a ThinkPad 390e with IBM EtherJet CardBus Adapter
> card, which I understand is really a Xircom card. I'm using
> the driver from pcmcia-cs 3.0.14 and things seem OK, except
> that ifconfig is showing a lot of TX errors:
>
> eth0 Link encap:Ethernet HWaddr 00:06:29:90:43:11
> inet addr:152.17.150.10 Bcast:152.17.255.255
> Mask:255.255.0.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:37176 errors:4 dropped:0 overruns:0 frame:0
> TX packets:7 errors:6137 dropped:0 overruns:0 carrier:6137
> collisions:0 txqueuelen:100
> Interrupt:3 Base address:0x200
>
> Any advice appreciated.
>
> This is with kernel 2.2.11. The CardBus adapter fires up thus
>
> Aug 18 16:42:18 pc10 cardmgr[916]: executing: 'insmod
> /lib/modules/2.2.11/pcmcia/tulip_cb.o'
> Aug 18 16:42:18 pc10 kernel: cs: cb_config(bus 32): vendor 0x115d,
> device 0x0003
> Aug 18 16:42:18 pc10 kernel: fn 0 bar 1: io 0x200-0x27f
> Aug 18 16:42:18 pc10 kernel: fn 0 bar 2: mem 0x6000b000-0x6000b7ff
> Aug 18 16:42:18 pc10 kernel: fn 0 bar 3: mem 0x6000a000-0x6000a7ff
> Aug 18 16:42:18 pc10 kernel: fn 0 rom: mem 0x60006000-0x60009fff
> Aug 18 16:42:18 pc10 kernel: tulip_attach(bus 32, function 0)
> Aug 18 16:42:18 pc10 kernel: tulip.c:v0.91 4/14/99
> [EMAIL PROTECTED] (modified by [EMAIL PROTECTED]
> for XIRCOM CBE, fixed by Doug Ledford)
> Aug 18 16:42:18 pc10 kernel: eth0: Xircom Cardbus Adapter (DEC 21143
> compatible mode) rev 3 at 0x200, 00:06:29:90:43:11, IRQ 3.
> Aug 18 16:42:18 pc10 kernel: eth0: MII transceiver #0 config 3100
> status 7809 advertising 01e1.
>
> --
> Allin Cottrell
> Department of Economics
> Wake Forest University, NC
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: linking (-ldl) [egcs-1.1.2] failure
Date: 19 Aug 1999 07:51:24 -0600
DEEK <[EMAIL PROTECTED]> writes:
> system: K62/450 128mb
> OS: RH 5.2 selective upgrade to 6.0
>
> Any time I attempt to complie something (now)
> it fails when linking to -ldl
libdl is provided by the glibc package:
$ rpm -qa /lib/libdl.so.2
glibc-2.1.1-6
Kurt
--
Common sense is the collection of prejudices acquired by age eighteen.
-- Albert Einstein
------------------------------
From: [EMAIL PROTECTED] (Doug DeJulio)
Subject: Re: most efficient way to zero out a partition?
Date: 19 Aug 1999 09:39:32 -0400
In article <[EMAIL PROTECTED]>,
Kaz Kylheku <[EMAIL PROTECTED]> wrote:
> It's a misconception that dd is needed for manipulating block
> devices.
But "dd" is really *useful* for manipulating block devices, when you
consider the bs= skip= and count= arguments together. So, long ago I
got into the habbit of using "dd" to access block devices. Later, I
picked up habbits like using the full file size when working with
floppies.
--
Doug DeJulio | mailto:[EMAIL PROTECTED]
HKS, Incorporated | http://www.hks.net/~ddj/
------------------------------
From: Etienne Lorrain <[EMAIL PROTECTED]>
Subject: Re: Importance of TX errors? (pcmcia)
Date: Thu, 19 Aug 1999 14:40:31 +0100
> > eth0 Link encap:Ethernet HWaddr 00:06:29:90:43:11
> > inet addr:152.17.150.10 Bcast:152.17.255.255
> > Mask:255.255.0.0
> > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > RX packets:37176 errors:4 dropped:0 overruns:0 frame:0
> > TX packets:7 errors:6137 dropped:0 overruns:0 carrier:6137
> > collisions:0 txqueuelen:100
> > Interrupt:3 Base address:0x200
> >
> > Any advice appreciated.
>
> Have you tried another cable ??
That is just Tx Errors, so you probably can still receive,
for instance try to receive from the network:
- the FAQ
- the documentation of net-tools
- the upgrade of ifconfig
------------------------------
From: "Edward Reid" <[EMAIL PROTECTED]>
Crossposted-To:
comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.openbsd.misc
Subject: Re: Source code licenses allow sharing between Linux and BSDs?
Date: Thu, 19 Aug 1999 9:22:53 -0400
On Tue, 17 Aug 1999 16:59:02 -0400, David Schwartz wrote
> Now imagine I put a poem up on a billboard. Do you think I could stop
> someone from distributing a photograph that included my billboard? Do you
Quite possibly yes, depending on the intent of the photograph (was it primarily
intended to be a copy of the poem, did it show the entire poem, does it fall
into one of the fair use categories such as criticism or education, is it
causing you damage, all the considerations which come into play regarding
copyright).
> think I could collect royalties from everyone who read the billboard?
No, because you published it. Under copyright, the restrictions apply to
publication, not reading. (Not that some corporations don't want to try to make
it mean more.)
> The crux is that no agreement entered into between the author and the
> licensee when the copyrighted work changes hands.
Don't confuse copyright with license provisions. Copyright is a strong and
automatic provision, but isn't extensible. All this license stuff arises
because people and companies want to place restrictions that are not part of
copyright. You can drop a copyrighted work from airplanes without losing your
rights under copyright law and treaties. This has nothing to do with license
provisions, which might apply even to non-copyrighted work.
See a real lawyer if you are worried about either one.
Edward Reid
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Talking to floppy and hard drive controllers under Linux
Date: Thu, 19 Aug 1999 14:51:40 GMT
Is this in every distribution? Where is it usually located?
Thanks!
In article <[EMAIL PROTECTED]>,
=?iso-8859-1?Q?[EMAIL PROTECTED]=E9-en-croute.fr?= wrote:
> On Thu, 19 Aug 1999 05:36:54 GMT, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> >I need to command the floppy and hard drive controllers of the
system.
> >(i.e. Directly command the floppy controller to format a track, read,
> >write and verify sectors). Does Linux have system calls or routines
> >for doing something like this? If so, where would I find them? What
> >header are they defined in?
>
> You should take a look at the source for "fdformat" in
> util-linux-2.9g-2.rpm
>
> SEE ALSO
> fd(4), setfdprm(8)
>
> --
> RIKHARDUR EGILSSON
> echo
'[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: =?US-ASCII?Q?=1B$B5uL5=1B?=(B <[EMAIL PROTECTED]>
Subject: Re: Best place in kernel for block encryption ?
Date: Thu, 19 Aug 1999 16:09:24 GMT
Chris Gregory <[EMAIL PROTECTED]> wrote:
: On 12 Aug 1999 15:17:19 GMT,
: R�khar�ur Egilsson <[EMAIL PROTECTED]�encroute.fr> wrote:
:
:
:>Has there been any discussion here about where the most efficient
:>place is in the kernel is to put an encryption layer.
:>
:>I would want it to work for all block devices. (i.e. all mountable
:>filesystems, both current and future).
:>
:>I think one such place might be the cache buffers, any comments
:>on that ? "linux/fs/buffer.c"
:>
:>
:>--
:> RIKHARDUR EGILSSON
:> echo '[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc
: You could look at what people have done already. There's
: linux-crypt-kernelpatches, which are for 2.0.11 kernel, or tcfs, which is
: distributed with crypt patches for the kernel, I don't know what version.
: Chris G.
--
there is also also the STEGANOGRAPHIC FILE SYSTEM (sfs)
which comes with a set of patches for the kernel (2.0.36-2.2.10)
as well as a tool-set. there is a little info at
http://www.linux-security.org/sfs/
im not sure how if it is what you want, but its worth
looking through their code...
kyomu
------------------------------
From: Allin Cottrell <[EMAIL PROTECTED]>
Subject: Re: Importance of TX errors? (pcmcia)
Date: Thu, 19 Aug 1999 12:10:26 -0400
Etienne Lorrain wrote:
(re my post on using the tulip_cb module from pcmcia-cs,
with an EtherJet CardBus Adapter in a ThinkPad 390e)
> > > eth0 Link encap:Ethernet HWaddr 00:06:29:90:43:11
> > > inet addr:152.17.150.10 Bcast:152.17.255.255
> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > RX packets:37176 errors:4 dropped:0 overruns:0 frame:0
> > > TX packets:7 errors:6137 dropped:0 overruns:0 carrier:6137
> > > collisions:0 txqueuelen:100
> >
> > Have you tried another cable ??
Yes, the cable is OK.
> That is just Tx Errors, so you probably can still receive...
The odd thing is that I seem able to receive and transmit OK.
I have tried inbound and outbound ftp and I'm getting accept-
able transfers. E.g. for a file transferred out from the
machine in question via ftp:
"1071026 bytes received in 1.12 secs (9.3e+02 Kbytes/sec)"
I'm not sure what the "carrier" errors actually mean, but
I wonder if the error message could be spurious? Note, though,
that it's not just ifconfig that's flagging errors. E.g.
cat /proc/dev/net gives (edited)
Inter-| Receive
face |bytes packets errs drop fifo frame
lo: 11250 98 0 0 0 0
eth0: 1429451 7741 4 0 0 0
| Transmit
|bytes packets errs drop fifo colls carrier
lo: 11250 98 0 0 0 0 0
eth0: 0 0 1353 0 0 0 1353
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: Question about segments
Date: Thu, 19 Aug 1999 17:13:09 +0000
On Thu, 19 Aug 1999, Bartosz Klimek wrote:
>Hello.
>
>There's something I don't understand about process segments. I suppose
>every process in Linux has a code segment, data segment, const data
>segment, stack segment. And now, if I have a pointer, e.g. char *p, it
>is a 32b offset. Look at this:
[SNIP]
>Question: how does the compiler (or whatever) know how to interpret the
>32b offsets in lines (1), (2), (3)? In each line p points to data in a
>different segment. Maybe the offsets are something more than just
>offsets in flat segments?
>
>AFAIR, you need an offset and a segment register to reach data in
>memory. But if you have the offset only, how do you know which segment
>register to use? Maybe the segments overlap? No, it can't be...
Yes, this is exactly the case. Linux x86 (and most unices on intel) have
a flat address space, in which all segment descriptors (note: not the
old real mode segments, protected mode descriptors!) point to the same
address space. The 32-bit offset allows addressing of all of the 4Gb of
address space on the 386+ and protection in implemented at the page
level, not the segment level, so why bother with those clumsy and ugly
segments?
The Pentium II, however, reintroduces this ugly concept, because offsets
are still 32-bit, but the CPU allows for a max. of 36 bits of address
space using the base pointer of the segment descriptor. There's much
discussion going on if Linux should be changed to support the bigger
address space, as the whole messy segment model would need to be
incorporated. Personally, I think not, the (64-bit) Alphas aren't that
expensive anymore these days and if you're willing to spend so much on
memory anyway, why bother with a processor that only has a hacked on
extension to handle it?
But that's an entirely other matter.
Hope this helps though,
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: most efficient way to zero out a partition?
Date: 19 Aug 1999 17:55:53 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: Ronald Cole <[EMAIL PROTECTED]>
In newsgroup: comp.os.linux.development.system
>
> I feel the need to zero out my /dev/sda10. It's a bit over 1-gig
> and so:
>
> dd if=/dev/zero of=/dev/sda10
>
> takes a *long* time. How would I figure out the optimal block size
> to get the job done in the shortest amount of time without resorting
> to trial-and-error?
>
Using "cat" is probably somewhat faster than "dd"... however, covering
the entire disk surface is what takes most of the time.
-hpa
--
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
------------------------------
From: "Pat Crean" <[EMAIL PROTECTED]>
Subject: Re: Importance of TX errors? (pcmcia)
Date: Thu, 19 Aug 1999 13:43:59 -0400
You need to update net-tools --- your old ifconfig is misinterpreting the
some newer data structures.... see the Changes file in
/usr/src/linux/Documentation.....
Allin Cottrell <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Etienne Lorrain wrote:
>
> (re my post on using the tulip_cb module from pcmcia-cs,
> with an EtherJet CardBus Adapter in a ThinkPad 390e)
>
> > > > eth0 Link encap:Ethernet HWaddr 00:06:29:90:43:11
> > > > inet addr:152.17.150.10 Bcast:152.17.255.255
> > > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > > RX packets:37176 errors:4 dropped:0 overruns:0 frame:0
> > > > TX packets:7 errors:6137 dropped:0 overruns:0 carrier:6137
> > > > collisions:0 txqueuelen:100
> > >
> > > Have you tried another cable ??
>
> Yes, the cable is OK.
>
> > That is just Tx Errors, so you probably can still receive...
>
> The odd thing is that I seem able to receive and transmit OK.
> I have tried inbound and outbound ftp and I'm getting accept-
> able transfers. E.g. for a file transferred out from the
> machine in question via ftp:
>
> "1071026 bytes received in 1.12 secs (9.3e+02 Kbytes/sec)"
>
> I'm not sure what the "carrier" errors actually mean, but
> I wonder if the error message could be spurious? Note, though,
> that it's not just ifconfig that's flagging errors. E.g.
> cat /proc/dev/net gives (edited)
>
> Inter-| Receive
> face |bytes packets errs drop fifo frame
> lo: 11250 98 0 0 0 0
> eth0: 1429451 7741 4 0 0 0
> | Transmit
> |bytes packets errs drop fifo colls carrier
> lo: 11250 98 0 0 0 0 0
> eth0: 0 0 1353 0 0 0 1353
>
> --
> Allin Cottrell
> Department of Economics
> Wake Forest University, NC
------------------------------
From: grant@nowhere. (Grant Edwards)
Subject: Re: Calling a BIOS interrupt
Date: Thu, 19 Aug 1999 17:39:56 GMT
In article <[EMAIL PROTECTED]>, Bartosz Klimek wrote:
>> I heard that Linux saves informations of the BIOS at boottime.
>What kind of information do you mean? Never heard of it anyway.
I believe that during bootup BIOS is used to find out how much
RAM is supposed to be present.
The loader program often used with Linux (LILO) also uses BIOS
to load the kernel from the hard drive.
Linux also uses the PCI BIOS somehow.
--
Grant Edwards grante Yow! Let's all show human
at CONCERN for REVEREND MOON's
visi.com legal difficulties!!
------------------------------
From: [EMAIL PROTECTED]�encroute.fr (R�khar�ur Egilsson)
Subject: Re: Talking to floppy and hard drive controllers under Linux
Date: 19 Aug 1999 16:01:04 GMT
Reply-To: =?iso-8859-1?Q?[EMAIL PROTECTED]=E9-en-croute.fr?=
On Thu, 19 Aug 1999 14:51:40 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Is this in every distribution? Where is it usually located?
>
>Thanks!
Hmm, I'm not sure where I got it from, but you can find the source
in a lots of places ..
ftp://ftp.cdrom.com/.4/linux/sunsite/utils/disk-management/fdformat.c
--
RIKHARDUR EGILSSON
echo '[q]sa[ln0=aln80%Pln80/snlbx]16isb15CB32EF3AF9C0E5D7272C3AF4F2snlbxq'|dc
------------------------------
From: [EMAIL PROTECTED] (Chris Butler)
Crossposted-To: linux.redhat.misc,linux.redhat.rpm,comp.os.linux.misc
Subject: Re: Why so inefficient source RPM's ??
Date: 19 Aug 1999 11:42:10 +0100
[comp.os.linux.development.system - 18 Aug 1999 17:44:42 -0400]
* Johan wrote *
> what if the builder doesn't offer a patch. you want to roll up a new
> rpm from the newer sources and wish to borrow from past rpm spec
> files. you have to download the source twice. it's annoying.
Not wanting to start dist-wars here, but Debian handles this a bit
better.
With debian source archives you have:
source_version-debian_version.dsc
source_version-debian_version.diff.gz
source_version.orig.tar.gz
The .dsc file contains information about the package, a lot of it taken
from the debian/control file (a bit like the top part of a spec file, it
would seem), and a list of the other files in the source archive, with
size and md5sum information. The .dsc is PGP-signed by the maintainer.
The .orig.tar.gz contains the upstream source. None of the
debian-specific modifications in there.
Finally, the .diff.gz contains all of the debian changes from the
upstream source. This includes the debian/ directory, holding all the
information necessary to create a .deb package. It may also contain
patches to the source to conform with Debian policy, or to fix important
bugs until the upstream contains the fix.
If you have downloaded the source from the upstream maintainer
seperatly, all you need to download is the .diff.gz (and the .dsc if you
want to check the .diff.gz's authenticity). It's usually just a matter
of patching the source with this .diff, and compiling a debian package
as normal.
--
Chris Butler
<[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
******************************
