* Re: [BUG] cs46xx: sound distortion after hours of use
From: Erik Mouw @ 2002-01-15 15:20 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <200201151224.g0FCO8E06163@Port.imtp.ilyichevsk.odessa.ua>
On Tue, Jan 15, 2002 at 02:24:00PM -0200, Denis Vlasenko wrote:
> I have noticed that after hours of palying mp3s thru my onboard audio
> (I use cs46xx module) sound becomes distorted (high-pitch noise).
>
> Restarting xmms does not help.
>
> rmmod cs46xx; modprobe cs46xx fixes it.
Are you running a battery monitor or something similar? In that case it
can cause the CPU to go into SMM with interrupts disabled to talk to
the batteries and completely forget about servicing the audio IRQ
thereby fscking up the sound. I had the same problems on my laptop and
killing gnome_battery_applet fixed it.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635
Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
^ permalink raw reply
* aic7xxx bus speed
From: Markus Walser @ 2002-01-15 15:30 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: linux-kernel
Hi
I've an aic7899: Ultra160 Wide scsi controller with a few disks
under an alpha ds20 running.
Now I'm having troubles getting 160MB/s bus speed on the
actual kernels (2.4.18pre2/2.5.2pre9). On the kernel 2.2.18 and
the redhat kernels 2.4.3-12, 2.4.9-13 I get full speed of 160MB/s.
But on the new kernel I get just 80MB/s per bus.
So I took a look at the differences between 2.4.9-13 and 2.4.18pre2.
You can find a diff of the aic7xxx driver here:
http://www.scs.ch/~walser/aic7xxx.diff
Basically its the aic7xxx version 6.2.4 insteed of 6.2.1 in the new
2.4.18pre2 kernel. I couldn't find where the problem comes from.
Here also some proc info:
[root@gugus /root]# uname -a
Linux gugus 2.5.2-pre9 #9 SMP Mon Jan 14 21:08:19 CET 2002 alpha unknown
[root@gugus /root]# cat /proc/scsi/aic7xxx/2
Adaptec AIC7xxx driver version: 6.2.4
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Channel A Target 0 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Channel A Target 0 Lun 0 Settings
Commands Queued 5
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 1 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Channel A Target 1 Lun 0 Settings
Commands Queued 5
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 2 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Channel A Target 2 Lun 0 Settings
Commands Queued 5
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 3 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Channel A Target 3 Lun 0 Settings
Commands Queued 5
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 4 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Channel A Target 4 Lun 0 Settings
Commands Queued 5
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 5 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Channel A Target 5 Lun 0 Settings
Commands Queued 5
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 6 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 7 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 8 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Curr: 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Channel A Target 8 Lun 0 Settings
Commands Queued 5
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 9 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 10 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 11 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 12 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 13 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 14 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 15 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
[root@petal0 /root]#
__________________________________________________________
[root@gugus /root]# uname -a
Linux gugus 2.4.9-13custom #1 SMP Mon Nov 12 12:56:49 CET 2001 alpha unknown
[root@gugus /root]# cat /proc/scsi/aic7xxx/2
Adaptec AIC7xxx driver version: 6.2.1
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs
Channel A Target 0 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Channel A Target 0 Lun 0 Settings
Commands Queued 6
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 1 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Channel A Target 1 Lun 0 Settings
Commands Queued 6
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 2 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Channel A Target 2 Lun 0 Settings
Commands Queued 6
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 3 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Channel A Target 3 Lun 0 Settings
Commands Queued 6
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 4 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Channel A Target 4 Lun 0 Settings
Commands Queued 6
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 5 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Channel A Target 5 Lun 0 Settings
Commands Queued 6
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 6 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 7 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 8 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Channel A Target 8 Lun 0 Settings
Commands Queued 6
Commands Active 0
Command Openings 253
Max Tagged Openings 253
Device Queue Frozen Count 0
Channel A Target 9 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 10 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 11 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 12 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 13 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 14 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Channel A Target 15 Negotiation Settings
User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
Do you have any hints to get back the full 160MB/s speed?
Regards, Markus
________________________________________________________
Supercomputing Systems AG email: walser@scs.ch
Markus Walser web: http://www.scs.ch
Technoparkstrasse 1 phone: +41 1 445 16 00
CH-8005 Zuerich fax: +41 1 445 16 10
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: Hans-Peter Jansen @ 2002-01-15 15:32 UTC (permalink / raw)
To: Nikita Danilov
Cc: trond.myklebust, Neil Brown, linux-kernel, Reiserfs mail-list
In-Reply-To: <15428.14268.730698.637522@laputa.namesys.com>
On Tuesday, 15. January 2002 15:07, Nikita Danilov wrote:
> Trond Myklebust writes:
> > >>>>> " " == Hans-Peter Jansen <hpj@urpla.net> writes:
> > > In syslog, this message appears: Jan 15 00:21:03 elfe kernel:
> > > nfs_refresh_inode: inode 50066 mode changed, 0100664 to 0120777
> >
> > The error is basically telling you that ReiserFS filehandles are being
> > reused by the server. Doesn't Reiser provide a generation count to
> > guard against this sort of thing?
>
> Yes, inode->i_generation is stored in the file handle:
> fs/reiserfs/inode.c:reiserfs_dentry_to_fh().
>
> Hans-Peter, what version of NFS are you using and have you remounted
> clients after upgrading to the newer kernel?
I can reproduce it with 2.4.5, 6, 13-ac7, 18-pre3 with and without Trond's
NFS-ALL patches applied. I don't understand your question, but testing this
implied several reboots of the server and some dozen reboots on the client.
The lm_sensors build reproduced it pretty stable (with a few exceptions,
and on different commands of the range ar, gcc and ln)
Test is pretty simple: clean make of lm_sensors almost all the time
triggers it. If not, just rm lib/libsensors* and make again. This
created certainly stale files lib/libsensors.so|lib/libsensors.so.1
from within the client. You can only get rid of them by rebooting or
removing them on the server.
> > My 'fix' just solves the immediate problem of the wrong file mode. It
> > does not solve the problems of data corruption that can occur when the
> > client is incapable of distinguishing the 'old' and 'new' files that
> > share the same filehandle.
>
> This requires i_generation overflow (modulo bug in reiserfs).
Please, try to reproduce it, and let us know, if you can reproduce it.
> > Cheers,
> > Trond
>
> Nikita.
Cheers,
Hans-Peter
^ permalink raw reply
* Re: Linux-2.5.2
From: Wayne.Brown @ 2002-01-15 15:27 UTC (permalink / raw)
To: Kernel Mailing List
The io_request_lock problem is still present in drivers/scsi/ppa.c:
ppa.c: In function `ppa_detect':
ppa.c:131: `io_request_lock' undeclared (first use in this function)
ppa.c:131: (Each undeclared identifier is reported only once
ppa.c:131: for each function it appears in.)
ppa.c: In function `ppa_interrupt':
ppa.c:850: `io_request_lock' undeclared (first use in this function)
make[2]: *** [ppa.o] Error 1
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: Oliver Xymoron @ 2002-01-15 15:34 UTC (permalink / raw)
To: Keith Owens; +Cc: Rob Landley, Linux Kernel List
In-Reply-To: <5641.1011094503@ocs3.intra.ocs.com.au>
On Tue, 15 Jan 2002, Keith Owens wrote:
> On Mon, 14 Jan 2002 09:19:01 -0500,
> Rob Landley <landley@trommello.org> wrote:
> >How much of the build process for the initramfs will be integrated with the
> >kernel build? Since the kernel won't boot without a matching initramfs, I
> >take it that some kind of initramfs will be a kernel build target now?
> >
> >There's been a lot of talk about having the source for a mini-libc (uclibc,
> >dietlibc, some combo) in the kernel tree, and other people saying we should
> >just grab the binary for build purposes. The most obvious model I can think
> >of for klibc staying seperate from the kernel is the user-space
> >pcmcia/cardbus hotplug stuff, but that DID get integrated into the kernel.
> >
> >The klibc source/binary debate still seems to be ongoing, but apart from
> >that, will the build process for initramfs be part of the kernel build or not?
>
> I am in two minds about this (but I am at one with my duality). Part
> of me says that users will want to tweak the initramfs process and they
> may want to use different versions of klibc, so klibc and building
> initramfs should be outside the kernel build. Another part says that
> users have to build initramfs before doing the install so initramfs and
> klibc should be part of kbuild.
>
> It will probably end up with klibc as part of the kernel tarball
> supported by kbuild. Generating initramfs will be done by a script,
> kbuild will supply a sample but users can copy and change the sample to
> suit their own requirements.
Better yet, we should do away with all install targets beyond assembling
the bootable images and provide sample install scripts in /scripts. Most
of it is already at odds with the distro's install and the remainder
becomes a maintenance issue with initramfs. Distro folks are going to be
working on initramfs-libc for their boot disks anyway and will undoubted
want to tweak such stuff greatly. Let's include Viro's
minimal-userspace-boot.c in scripts along with a
build-minimal-initramfs.sh and leave it at that.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: Trond Myklebust @ 2002-01-15 15:38 UTC (permalink / raw)
To: Nikita Danilov
Cc: Nikita Danilov, Neil Brown, Hans-Peter Jansen, linux-kernel,
Reiserfs mail-list, David L. Parsley
In-Reply-To: <15428.19063.859280.833041@laputa.namesys.com>
On Tuesday 15. January 2002 16:27, Nikita Danilov wrote:
> In reiserfs there is no static inode table, so we keep global generation
> counter in a super block which is incremented on each inode deletion,
> this generation is stored in the new inodes. Not that good as per-inode
> generation, but we cannot do better without changing disk format.
Am I right in assuming that you therefore cannot check that the filehandle is
stale if the client presents you with the filehandle of the 'old' inode
(prior to deletion)?
However if the client compares the 'old' and 'new' filehandle, it will find
them to be different?
Cheers,
Trond
^ permalink raw reply
* Re: 2.5.2 / IDE cdrom_read_intr: data underrun / end_request: I/O error
From: David Dyck @ 2002-01-15 15:47 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-kernel
In-Reply-To: <20020115101951.A31257@suse.de>
On Tue, 15 Jan 2002 at 10:19 +0100, Jens Axboe <axboe@suse.de> wrote:
> On Mon, Jan 14 2002, David Dyck wrote:
> >
> > I'm still getting data underrun errors using 2.5.2
> > that don't occur using 2.4.18-pre3.
>
> I'll check up on that, mind checking when this happened exactly in the
> 2.5 series?
I know it fails in 2.5.1, and 2.5.2
(do you need more resolution -- the problem is that many of these
early kernels don't shut down well on my computer, so I end up
fsck'ing after restart. (I guess this should encourage me to
convert to ext3 :-)
I'd be willing to try a couple other ones if you have
specific -pre patches you'd like resolution on.
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery --the elegant solution)
From: Marco Colombo @ 2002-01-15 15:47 UTC (permalink / raw)
To: Giacomo Catenazzi; +Cc: linux-kernel
In-Reply-To: <3C444441.3080608@debian.org>
On Tue, 15 Jan 2002, Giacomo Catenazzi wrote:
>
>
> Marco Colombo wrote:
>
> >>
> >>The main discussion was in kbuild-devel list.
> >>
> >
> > Uh, my mailbox hurts just at the thought of even more posting on the suject.
> >
>
>
> In kbuild: less people, less traffic, more discussion, less flames
>
> > Kernel tarballs are for hackers. Marcelo can't test any configuration
> > the autoconfigurator can produce. So basically it means an untested
> > kernel. Running untested kernel isn't a job for Joe User, and never
> > will be.
>
>
> Also what are the stable series?
The *starting* point to build a working solution. And stable != supported.
The "working solution" being a distro kernel (well, the whole thing really),
which happens to be supported (and supportable), too...
> But you think your distribution test the kernel in all possible
> use? With all possible hardware configuration?
They *virtually* do. Why do they have (slightly) DIFFERENT hardware
compatibility lists? I don't care if they do really test a given HW
configuration as long as they support it. You can't ask Marcelo to
actively support any HW conf. I'd expect him to "support" just the HW
he uses to build tarballs.
> Autoconfiguration will configure a compile and booting kernel.
> (but on old machine). Neither vendor can assure you that the kernel
> will work for a particolar permutation of hardware, and mainly
> it is indipendent from configuration.
Uh? After autoconfiguration you *hope* the kernel boots. In late 2.2
times, vanilla 2.2 used to be almost useless for just less-than-naive
users. Think of RAID @ redhat, or ReiserFS @ suse.
BTW, if I buy a RH Linux CD set (+support), and install it on a PC made
by parts all included in RH HW compatibility list, I expect:
1) it to work;
2) failing 1), Red Hat to solve any problem when I call them for support;
3) failing 2), Red Hat to return the money for the CDs.
That's what vendors are for.
> > Vendors and kernel developers have different goals. That horrible hack
> > that fixes some bug or misbehavior fits fine into a vendor kernel, and
> > has no place in Marcelo's tree; the same for that C++ written, cross OS
> > crap driver for hardware XYZ. Users want it, vendors provide it.
> > Different goals, different targets.
>
>
> Change distribution. In Debian/unstable developers and distribution are
> hardly linked!
Are you suggesting that Joe User should run Debian/*unstable*? What
it Debian/stable for, then?
> Why do you need someone in the 'layer' between developers
> and user?
The user isn't expected to do any QA. And Marcelo and other kernel
maitainers aren't, either.
> > Autoconfiguration is nice. But please move the topic elsewhere.
>
> Right. Let stop it
No problem for me. Feel free to answer me privately, as the above is
hardly kernel-related (it applies to any other piece of software).
>
> giacomo
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: Nikita Danilov @ 2002-01-15 16:47 UTC (permalink / raw)
To: Trond Myklebust
Cc: Neil Brown, Hans-Peter Jansen, linux-kernel, Reiserfs mail-list,
David L. Parsley
In-Reply-To: <E16QVf3-0002NG-00@charged.uio.no>
Trond Myklebust writes:
> On Tuesday 15. January 2002 16:27, Nikita Danilov wrote:
>
> > In reiserfs there is no static inode table, so we keep global generation
> > counter in a super block which is incremented on each inode deletion,
> > this generation is stored in the new inodes. Not that good as per-inode
> > generation, but we cannot do better without changing disk format.
>
> Am I right in assuming that you therefore cannot check that the filehandle is
> stale if the client presents you with the filehandle of the 'old' inode
> (prior to deletion)?
> However if the client compares the 'old' and 'new' filehandle, it will find
> them to be different?
Sorry for being vague. Reiserfs keeps global "inode generation counter"
->s_inode_generation in a super block. This counter is incremented each
time reiserfs inode is being deleted on a disk. When new inode is
created, current value of ->s_inode_generation is stored in inode's
on-disk representation. Inode number (objectid in reiserfs parlance) is
reusable once inode was deleted. The same pair (i_ino, i_generation) can
be assigned to different inode only after ->s_inode_generation
overflows, which requires 2**32 file deletions.
So, no, reiserfs can tell stale filehandle, although not as reliable as
file systems with static inode tables.
Hans-Peter, please tell me, what reiserfs format are you using. 3.5
doesn't support NFS reliably. If you are using 3.5 you'll have to
upgrade to 3.6 format (copy data to the new file system). mount -o conv
will not eliminate this problem completely, but will make it much less
probable, so you can try this first.
>
> Cheers,
> Trond
>
Nikita.
^ permalink raw reply
* Re: aic7xxx bus speed
From: Justin T. Gibbs @ 2002-01-15 15:50 UTC (permalink / raw)
To: Markus Walser; +Cc: linux-kernel
In-Reply-To: <3C444AFA.8000605@scs.ch>
>Hi
>I've an aic7899: Ultra160 Wide scsi controller with a few disks
>under an alpha ds20 running.
>Now I'm having troubles getting 160MB/s bus speed on the
>actual kernels (2.4.18pre2/2.5.2pre9). On the kernel 2.2.18 and
>the redhat kernels 2.4.3-12, 2.4.9-13 I get full speed of 160MB/s.
>But on the new kernel I get just 80MB/s per bus.
You probably have IBM drives that say they are SCSI-2 yet can do
160 speeds. There is a check in the driver that prevents it from
negotiating from SCSI-2 drives so as to not blow up on SCSI-2 devices
that don't support the new negotiation message type. I have a fix
to work around IBM's mistake in the next driver release.
--
Justin
^ permalink raw reply
* Re: Penelope builds a kernel
From: salvador @ 2002-01-15 15:53 UTC (permalink / raw)
To: esr; +Cc: Richard Gooch, linux-kernel
In-Reply-To: <20020114174523.E23081@thyrsus.com>
"Eric S. Raymond" wrote:
> Richard Gooch <rgooch@ras.ucalgary.ca>:
> > You know, I'm not really interested in whether Melvin or Penelope get
> > a root or not, and it's never occurred to me that kernel design should
> > be based on that.
>
> The phrase "get a root" is entertainingly ambiguous in this context, is it not?
>
> Storytelling is the most effective form of exposition.
Yes, if you mean "to confuse people" ;-)
> It's a way to pull
> technical issues out of the realm of abstraction,
Or get really out of topic. Be careful with your examples, sometimes they have
small errors here and there and the result, even when looks coherent, is invalid.
> and help designers
> realize that there are (at least potentially) real people involved.
Eric, if you want to create a tool that looks for the installed hardware/vendor
configuratio/etc. and from all of this information creates a configure file in the
Linux source tree go ahead. I don't think anybody will stop you if that's a
separated tool and not part of the Linux source tree.
Lets use an example, looks like you really like examples:
1) You create a project called "Linux autoconf".
2) You make it available as a tarball.
3) Some user that likes it downloads and installs the Linux kernel sources.
4) Same user downloads your "nice" tool and also installs it.
5) This user instead of using the traditional configuration methods just runs your
tool and gets all solved .... or all fkd up ;-)
I don't think anybody will stop you from doing such a tool, in fact nobody can,
but you'll need to look for help in other list ;-))
SET
--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set@computer.org set@ieee.org
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
^ permalink raw reply
* Re: Memory problem with bttv driver
From: Gerd Knorr @ 2002-01-15 15:16 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: linux-kernel
In-Reply-To: <20020115144652.46d9ee18.skraw@ithnet.com>
On Tue, Jan 15, 2002 at 02:46:52PM +0100, Stephan von Krawczynski wrote:
> On Tue, 15 Jan 2002 14:20:17 +0100
> Gerd Knorr <kraxel@bytesex.org> wrote:
>
> > Yes. Instead of remapping vmalloced kernel memory it gives you shared
> > anonymous pages, then does zerocopy DMA using kiobufs. You may run in
> > trouble with >4GB machines.
>
> Interesting.
> What's the problem on > 4GB ?
The bt878/848 is a 32bit PCI device, it simply can't go DMA to main
memory above 4GB. At least on ia32, on architecures with a iommu
(sparc, ...) it should work without trouble.
Gerd
--
#define ENOCLUE 125 /* userland programmer induced race condition */
^ permalink raw reply
* [ANNOUNCE][PATCH] New fs to control access to system resources
From: Olaf Dietsche @ 2002-01-15 16:01 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]
Hi,
this is a new file system to control access to system resources.
Currently it controls access to inet_bind() with ports < 1024 only.
With this patch, there's no need anymore to run internet daemons as
root. You can individually configure which user/program can bind to
ports below 1024.
For example, you can say, user www is allowed to bind to port 80 or
user mail is allowed to bind to port 25. Then, you can run apache as
user www and sendmail as user mail. Now, you don't have to rely on
apache or sendmail giving up superuser rights to enhance security.
To use this, you need to mount the file system and do a chown on the
appropriate ports:
# mount -t accessfs none /mnt
# chown www /mnt/net/ipv4/bind/80
# chown mail /mnt/net/ipv4/bind/25
...
You can grant access to a group for individual ports as well. Just say:
# chgrp lp /mnt/net/ipv4/bind/515
# chown g+x /mnt/net/ipv4/bind/515
... and you're done.
This patch is against 2.4.14, but it applies with offsets to 2.4.17
and 2.5.2 as well. However, I have built and tested 2.4.14 only.
Now, I would like to here from you, whether you find this useful or
not, have any suggestions, objections ... please tell me.
Of course, comments on the code are welcome too :-).
Thanks for your time.
Regards, Olaf.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: New linux accessfs --]
[-- Type: text/x-patch, Size: 14294 bytes --]
diff -X dontdiff -urN v2.4.14/Documentation/Configure.help linux/Documentation/Configure.help
--- v2.4.14/Documentation/Configure.help Mon Nov 5 22:40:59 2001
+++ linux/Documentation/Configure.help Fri Jan 11 21:45:16 2002
@@ -19179,6 +19179,34 @@
To use this option, you have to check that the "/proc file system
support" (CONFIG_PROC_FS) is enabled, too.
+Accessfs support (EXPERIMENTAL)
+CONFIG_ACCESS_FS
+ This is a new file system to control access to system resources.
+ Currently it controls access to bind() with ports < 1024 only.
+
+ With this file system, there's no need anymore to run internet daemons
+ as root. You can individually configure which user/program can bind to
+ ports below 1024.
+
+ For example, you can say, user www is allowed to bind to port 80 or
+ user mail is allowed to bind to port 25. Then, you can run apache as
+ user www and sendmail as user mail. Now, you don't have to rely on
+ apache or sendmail giving up superuser rights to enhance security.
+
+ To use this file system, you need to mount the file system somewhere
+ and do a chown on the appropriate ports:
+
+ # mount -t accessfs none /mnt
+ # chown www /mnt/net/ipv4/bind/80
+ # chown mail /mnt/net/ipv4/bind/25
+
+ You can grant access to a group for individual ports as well. Just say:
+
+ # chgrp lp /mnt/net/ipv4/bind/515
+ # chown g+x /mnt/net/ipv4/bind/515
+
+ If you're unsure, say N.
+
#
# A couple of things I keep forgetting:
# capitalize: AppleTalk, Ethernet, DOS, DMA, FAT, FTP, Internet,
diff -X dontdiff -urN v2.4.14/fs/Config.in linux/fs/Config.in
--- v2.4.14/fs/Config.in Mon Nov 5 22:40:59 2001
+++ linux/fs/Config.in Thu Jan 10 19:49:32 2002
@@ -78,6 +78,8 @@
tristate 'UFS file system support (read only)' CONFIG_UFS_FS
dep_mbool ' UFS file system write support (DANGEROUS)' CONFIG_UFS_FS_WRITE $CONFIG_UFS_FS $CONFIG_EXPERIMENTAL
+dep_bool 'Accessfs support (EXPERIMENTAL)' CONFIG_ACCESS_FS $CONFIG_EXPERIMENTAL
+
if [ "$CONFIG_NET" = "y" ]; then
mainmenu_option next_comment
diff -X dontdiff -urN v2.4.14/fs/Makefile linux/fs/Makefile
--- v2.4.14/fs/Makefile Mon Nov 5 22:40:59 2001
+++ linux/fs/Makefile Thu Jan 10 19:39:46 2002
@@ -64,6 +64,7 @@
subdir-$(CONFIG_REISERFS_FS) += reiserfs
subdir-$(CONFIG_DEVPTS_FS) += devpts
subdir-$(CONFIG_SUN_OPENPROMFS) += openpromfs
+subdir-$(CONFIG_ACCESS_FS) += accessfs
obj-$(CONFIG_BINFMT_AOUT) += binfmt_aout.o
diff -X dontdiff -urN v2.4.14/fs/accessfs/Makefile linux/fs/accessfs/Makefile
--- v2.4.14/fs/accessfs/Makefile Thu Jan 1 01:00:00 1970
+++ linux/fs/accessfs/Makefile Thu Jan 10 19:42:52 2002
@@ -0,0 +1,9 @@
+#
+# Makefile for the linux accessfs routines.
+#
+
+O_TARGET := accessfs.o
+obj-y := inode.o
+export-objs := inode.o
+
+include $(TOPDIR)/Rules.make
diff -X dontdiff -urN v2.4.14/fs/accessfs/inode.c linux/fs/accessfs/inode.c
--- v2.4.14/fs/accessfs/inode.c Thu Jan 1 01:00:00 1970
+++ linux/fs/accessfs/inode.c Fri Jan 11 22:08:26 2002
@@ -0,0 +1,355 @@
+/* Copyright (c) 2001 Olaf Dietsche
+ *
+ * Access permission filesystem for Linux.
+ */
+
+#include <linux/accessfs_fs.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/pagemap.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/locks.h>
+
+#include <asm/uaccess.h>
+
+typedef struct accessfs_entry afs_entry_t;
+typedef struct accessfs_direntry afs_dir_t;
+
+#define ACCESSFS_MAGIC 0x3c1d36e7
+
+static struct inode_operations accessfs_inode_operations;
+static struct file_operations accessfs_dir_file_operations;
+static struct inode_operations accessfs_dir_inode_operations;
+
+static int accessfs_statfs(struct super_block *sb, struct statfs *buf)
+{
+ buf->f_type = ACCESSFS_MAGIC;
+ buf->f_bsize = PAGE_CACHE_SIZE;
+ buf->f_namelen = 255;
+ return 0;
+}
+
+static int accessfs_readdir(struct file *filp, void *dirent, filldir_t filldir)
+{
+ int i;
+ struct dentry *dentry = filp->f_dentry;
+
+ i = filp->f_pos;
+ switch (i) {
+ case 0:
+ if (filldir(dirent, ".", 1, i, dentry->d_inode->i_ino, DT_DIR) < 0)
+ break;
+
+ ++i;
+ ++filp->f_pos;
+ /* NO break; */
+ case 1:
+ if (filldir(dirent, "..", 2, i, dentry->d_parent->d_inode->i_ino, DT_DIR) < 0)
+ break;
+
+ ++i;
+ ++filp->f_pos;
+ /* NO break; */
+ default: {
+ afs_dir_t *de = (afs_dir_t *) dentry->d_inode->u.generic_ip;
+ struct list_head *list;
+ int j;
+
+ list = de->children.next;
+
+ for (j = 2; j < i && list != &de->children; ++j)
+ list = list->next;
+
+ while (list != &de->children) {
+ afs_entry_t *pe = list_entry(list, afs_entry_t, siblings);
+ if (filldir(dirent, pe->name, strlen(pe->name), filp->f_pos, pe->ino, DT_UNKNOWN) < 0)
+ break;
+
+ ++filp->f_pos;
+ list = list->next;
+ }
+ }
+
+ break;
+ }
+
+ return 0;
+}
+
+static afs_entry_t *accessfs_lookup_entry(afs_entry_t *pe, const char *name, int len)
+{
+ if (S_ISDIR(pe->attr->mode)) {
+ struct list_head *list;
+ afs_dir_t *dir = (afs_dir_t *) pe;
+ list_for_each(list, &dir->children) {
+ afs_entry_t *de = list_entry(list, afs_entry_t, siblings);
+ if (strncmp(de->name, name, len) == 0 && de->name[len] == 0)
+ return de;
+ }
+ }
+
+ return NULL;
+}
+
+static struct dentry *accessfs_lookup(struct inode *dir, struct dentry *dentry)
+{
+ struct inode *inode = NULL;
+ afs_entry_t *pe;
+ pe = accessfs_lookup_entry(dir->u.generic_ip, dentry->d_name.name, dentry->d_name.len);
+ if (pe)
+ inode = iget(dir->i_sb, pe->ino);
+
+ d_add(dentry, inode);
+ return NULL;
+}
+
+static afs_dir_t accessfs_rootdir = {
+ { "/",
+ LIST_HEAD_INIT(accessfs_rootdir.node.hash),
+ LIST_HEAD_INIT(accessfs_rootdir.node.siblings),
+ 1, &accessfs_rootdir.attr },
+ NULL, LIST_HEAD_INIT(accessfs_rootdir.children),
+ { 0, 0, S_IFDIR | 0755 }
+};
+
+static void accessfs_init_inode(struct inode *inode, afs_entry_t *pe)
+{
+ inode->u.generic_ip = pe;
+ inode->i_uid = pe->attr->uid;
+ inode->i_gid = pe->attr->gid;
+ inode->i_mode = pe->attr->mode;
+/*
+ inode->i_blksize = PAGE_CACHE_SIZE;
+ inode->i_blocks = 0;
+ inode->i_rdev = NODEV;
+*/
+ inode->i_atime = inode->i_mtime = inode->i_ctime = 0;
+ switch (inode->i_mode & S_IFMT) {
+ case S_IFREG:
+ inode->i_op = &accessfs_inode_operations;
+ break;
+ case S_IFDIR:
+ inode->i_op = &accessfs_dir_inode_operations;
+ inode->i_fop = &accessfs_dir_file_operations;
+ break;
+ default:
+ printk(KERN_ERR "accessfs_init_inode(): '%s' unhandled mode=%d\n", pe->name, inode->i_mode);
+ BUG();
+ break;
+ }
+}
+
+static struct inode *accessfs_get_root_inode(struct super_block *sb)
+{
+ struct inode *inode = new_inode(sb);
+ if (inode) {
+/* inode->i_ino = accessfs_rootdir.node.ino; */
+ accessfs_init_inode(inode, &accessfs_rootdir.node);
+ accessfs_rootdir.node.ino = inode->i_ino;
+ }
+
+ return inode;
+}
+
+static LIST_HEAD(hash);
+
+static int accessfs_node_init(afs_dir_t *parent, afs_entry_t *de, const char *name, size_t len, struct access_attr *attr, mode_t mode)
+{
+ static unsigned long ino = 1;
+ de->name = kmalloc(len + 1, GFP_KERNEL);
+ if (de->name == NULL)
+ return -ENOMEM;
+
+ strncpy(de->name, name, len);
+ de->name[len] = 0;
+ de->ino = ++ino;
+ de->attr = attr;
+ de->attr->uid = 0;
+ de->attr->gid = 0;
+ de->attr->mode = mode;
+ list_add_tail(&de->hash, &hash);
+ list_add_tail(&de->siblings, &parent->children);
+ return 0;
+}
+
+static int accessfs_mknod(afs_dir_t *dir, const char *name, struct access_attr *attr)
+{
+ afs_entry_t *pe = kmalloc(sizeof(afs_entry_t), GFP_KERNEL);
+ if (pe == NULL)
+ return -ENOMEM;
+
+ accessfs_node_init(dir, pe, name, strlen(name), attr, S_IFREG | attr->mode);
+ return 0;
+}
+
+static afs_dir_t *accessfs_mkdir(afs_dir_t *parent, const char *name, size_t len)
+{
+ int error;
+ afs_dir_t *dir = kmalloc(sizeof(afs_dir_t), GFP_KERNEL);
+ if (dir == NULL)
+ return NULL;
+
+ error = accessfs_node_init(parent, &dir->node, name, len, &dir->attr, S_IFDIR | 0755);
+ if (error) {
+ kfree(dir);
+ return NULL;
+ }
+
+ dir->parent = parent;
+ INIT_LIST_HEAD(&dir->children);
+ return dir;
+}
+
+afs_dir_t *accessfs_make_dirpath(const char *name)
+{
+ afs_dir_t *dir = &accessfs_rootdir;
+ const char *slash;
+ do {
+ afs_entry_t *de;
+ size_t len;
+ while (*name == '/')
+ ++name;
+
+ slash = strchr(name, '/');
+ len = slash ? slash - name : strlen(name);
+ de = accessfs_lookup_entry(&dir->node, name, len);
+ if (de == NULL) {
+ dir = accessfs_mkdir(dir, name, len);
+ } else if (S_ISDIR(de->attr->mode)) {
+ dir = (afs_dir_t *) de;
+ } else {
+ return NULL;
+ }
+
+ if (dir == NULL)
+ return NULL;
+
+ name = slash + 1;
+ } while (slash != NULL);
+
+ return dir;
+}
+
+static void accessfs_unlink(afs_entry_t *pe)
+{
+ list_del(&pe->hash);
+ list_del(&pe->siblings);
+ kfree(pe->name);
+ kfree(pe);
+}
+
+static int accessfs_notify_change(struct dentry *dentry, struct iattr *iattr)
+{
+ struct inode *i = dentry->d_inode;
+ int error = inode_setattr(i, iattr);
+ if (!error) {
+ afs_entry_t *pe = (afs_entry_t *) i->u.generic_ip;
+ pe->attr->uid = i->i_uid;
+ pe->attr->gid = i->i_gid;
+ pe->attr->mode = i->i_mode;
+ }
+
+ return error;
+}
+
+static void accessfs_read_inode(struct inode *inode)
+{
+ ino_t ino = inode->i_ino;
+ struct list_head *list;
+ list_for_each(list, &hash) {
+ afs_entry_t *pe = list_entry(list, afs_entry_t, hash);
+ if (pe->ino == ino) {
+ accessfs_init_inode(inode, pe);
+ return;
+ }
+ }
+}
+
+static struct inode_operations accessfs_inode_operations = {
+ setattr: accessfs_notify_change,
+};
+
+static struct inode_operations accessfs_dir_inode_operations = {
+ lookup: accessfs_lookup,
+ setattr: accessfs_notify_change,
+};
+
+static struct file_operations accessfs_dir_file_operations = {
+ readdir: accessfs_readdir,
+};
+
+static struct super_operations accessfs_ops = {
+ read_inode: accessfs_read_inode,
+ statfs: accessfs_statfs,
+};
+
+static struct super_block *accessfs_read_super(struct super_block *sb, void *data, int silent)
+{
+ struct inode *inode;
+ struct dentry *root;
+
+ sb->s_blocksize = PAGE_CACHE_SIZE;
+ sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
+ sb->s_magic = ACCESSFS_MAGIC;
+ sb->s_op = &accessfs_ops;
+ inode = accessfs_get_root_inode(sb);
+ if (!inode)
+ return NULL;
+
+ root = d_alloc_root(inode);
+ if (!root) {
+ iput(inode);
+ return NULL;
+ }
+
+ sb->s_root = root;
+ return sb;
+}
+
+int accessfs_permitted(struct access_attr *p, int mask)
+{
+ mode_t mode = p->mode;
+ if (current->fsuid == p->uid)
+ mode >>= 6;
+ else if (in_group_p(p->gid))
+ mode >>= 3;
+
+ return (mode & mask) == mask;
+}
+
+void accessfs_register(afs_dir_t *dir, const char *name, struct access_attr *attr)
+{
+ if (dir) {
+ accessfs_mknod(dir, name, attr);
+ }
+}
+
+void accessfs_unregister(afs_dir_t *dir, const char *name)
+{
+ afs_entry_t *pe = accessfs_lookup_entry(&dir->node, name, strlen(name));
+ if (pe) {
+ accessfs_unlink(pe);
+ }
+}
+
+static DECLARE_FSTYPE(accessfs_fs_type, "accessfs", accessfs_read_super, FS_SINGLE);
+
+static int __init init_accessfs_fs(void)
+{
+ return register_filesystem(&accessfs_fs_type);
+}
+
+static void __exit exit_accessfs_fs(void)
+{
+ unregister_filesystem(&accessfs_fs_type);
+}
+
+module_init(init_accessfs_fs)
+module_exit(exit_accessfs_fs)
+
+EXPORT_SYMBOL(accessfs_permitted);
+EXPORT_SYMBOL(accessfs_make_dirpath);
+EXPORT_SYMBOL(accessfs_register);
+EXPORT_SYMBOL(accessfs_unregister);
diff -X dontdiff -urN v2.4.14/include/linux/accessfs_fs.h linux/include/linux/accessfs_fs.h
--- v2.4.14/include/linux/accessfs_fs.h Thu Jan 1 01:00:00 1970
+++ linux/include/linux/accessfs_fs.h Fri Jan 11 22:10:18 2002
@@ -0,0 +1,38 @@
+/* -*- mode: c -*- */
+#ifndef __accessfs_fs_h_included__
+#define __accessfs_fs_h_included__ 1
+
+/* Copyright (c) 2001 Olaf Dietsche
+ *
+ * $Log$
+ */
+
+#include <linux/fs.h>
+
+struct access_attr {
+ uid_t uid;
+ gid_t gid;
+ mode_t mode;
+};
+
+struct accessfs_entry {
+ char *name;
+ struct list_head hash;
+ struct list_head siblings;
+ ino_t ino;
+ struct access_attr *attr;
+};
+
+struct accessfs_direntry {
+ struct accessfs_entry node;
+ struct accessfs_direntry *parent;
+ struct list_head children;
+ struct access_attr attr;
+};
+
+extern int accessfs_permitted(struct access_attr *p, int mask);
+extern struct accessfs_direntry *accessfs_make_dirpath(const char *name);
+extern void accessfs_register(struct accessfs_direntry *dir, const char *name, struct access_attr *attr);
+extern void accessfs_unregister(struct accessfs_direntry *dir, const char *name);
+
+#endif
diff -X dontdiff -urN v2.4.14/net/ipv4/af_inet.c linux/net/ipv4/af_inet.c
--- v2.4.14/net/ipv4/af_inet.c Mon Nov 5 18:46:12 2001
+++ linux/net/ipv4/af_inet.c Thu Jan 10 20:14:29 2002
@@ -116,6 +116,9 @@
#if defined(CONFIG_NET_RADIO) || defined(CONFIG_NET_PCMCIA_RADIO)
#include <linux/wireless.h> /* Note : will define WIRELESS_EXT */
#endif /* CONFIG_NET_RADIO || CONFIG_NET_PCMCIA_RADIO */
+#ifdef CONFIG_ACCESS_FS
+#include <linux/accessfs_fs.h>
+#endif
struct linux_mib net_statistics[NR_CPUS*2];
@@ -467,6 +470,10 @@
return(0);
}
+#ifdef CONFIG_ACCESS_FS
+static struct access_attr bind_to_port[PROT_SOCK];
+#endif
+
/* It is off by default, see below. */
int sysctl_ip_nonlocal_bind;
@@ -503,7 +510,11 @@
return -EADDRNOTAVAIL;
snum = ntohs(addr->sin_port);
+#ifdef CONFIG_ACCESS_FS
+ if (snum && snum < PROT_SOCK && !accessfs_permitted(&bind_to_port[snum], MAY_EXEC))
+#else
if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
+#endif
return -EACCES;
/* We keep a pair of addresses. rcv_saddr is the one
@@ -1101,6 +1112,21 @@
}
}
+#ifdef CONFIG_ACCESS_FS
+static void accessfs_init(void)
+{
+ struct accessfs_direntry *dir = accessfs_make_dirpath("net/ipv4/bind");
+ int i;
+ for (i = 1; i < PROT_SOCK; ++i) {
+ char buf[sizeof("1023")];
+ bind_to_port[i].uid = 0;
+ bind_to_port[i].gid = 0;
+ bind_to_port[i].mode = S_IXUSR;
+ sprintf(buf, "%d", i);
+ accessfs_register(dir, buf, &bind_to_port[i]);
+ }
+}
+#endif
/*
* Called by socket.c on kernel startup.
@@ -1197,6 +1223,11 @@
proc_net_create ("tcp", 0, tcp_get_info);
proc_net_create ("udp", 0, udp_get_info);
#endif /* CONFIG_PROC_FS */
+
+#ifdef CONFIG_ACCESS_FS
+ accessfs_init();
+#endif
+
return 0;
}
module_init(inet_init);
^ permalink raw reply
* Re: Linux-2.5.2
From: Paul Larson @ 2002-01-15 15:46 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Linus Torvalds, Kernel Mailing List
In-Reply-To: <Pine.LNX.4.40.0201142042570.935-100000@blue1.dev.mcafeelabs.com>
On Mon, 14 Jan 2002, Davide Libenzi wrote:
> Linus, i've a weird behavior with 2.5.2
> swapon first fails at boot ( early stage ) then it succeed ( late boot
> stage ) but the swap is not actually activated. Running swapon by hand it
> reports a seccessful operation but the swap is not on.
> I'm trying to understand what is happening ...
I am having this problem also
# swapon /dev/hda2
swapon: /dev/hda2: Success
# free
total used free shared buffers cached
Mem: 254492 40236 214256 0 2220 22432
-/+ buffers/cache: 15584 238908
Swap: 0 0 0
#
-Paul Larson
^ permalink raw reply
* Re: Linux-2.5.2
From: Alexander Viro @ 2002-01-15 16:08 UTC (permalink / raw)
To: Paul Larson; +Cc: Davide Libenzi, Linus Torvalds, Kernel Mailing List
In-Reply-To: <Pine.LNX.4.33.0201150943210.3557-100000@eclipse.ltc.austin.ibm.com>
On Tue, 15 Jan 2002, Paul Larson wrote:
> On Mon, 14 Jan 2002, Davide Libenzi wrote:
> > Linus, i've a weird behavior with 2.5.2
> > swapon first fails at boot ( early stage ) then it succeed ( late boot
> > stage ) but the swap is not actually activated. Running swapon by hand it
> > reports a seccessful operation but the swap is not on.
> > I'm trying to understand what is happening ...
>
> I am having this problem also
ftp.math.psu.edu/pub/viro/LB38-fix-C2
^ permalink raw reply
* Re: [RFC] klibc requirements
From: Doug McNaught @ 2002-01-15 16:15 UTC (permalink / raw)
To: David Lang
Cc: Felix von Leitner, Albert D. Cahalan, Greg KH, linux-kernel,
andersen
In-Reply-To: <Pine.LNX.4.40.0201150649430.23491-100000@dlang.diginsite.com>
David Lang <david.lang@digitalinsight.com> writes:
> as an example (not for the boot process, but an example of a replacement
> libc use) I use the firewall toolkit, it has been around for a _loooong_
> time (in software terms anyway) and has a firly odd licence (free for you
> to use, source available, cannot sell it) which is not compatable with the
> GPL. with glibc staticly linked this makes huge binaries, with libc5 they
> were a lot smaller. I would like to try to use this small libc for these
> proxies, but if the library is GPL, not LGPL I'm not allowed to.
Hmm, I think you can; you just can't redistribute it. Can you even
redistribute fwtk on non-commercial terms?
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
^ permalink raw reply
* Unresponding 2.4.18-pre3 with yahoo and mozilla
From: Vassilis Virvilis @ 2002-01-15 16:16 UTC (permalink / raw)
To: linux-kernel
Halo,
I have just crashed linux 2.4.18pre3 several times
with mozilla 0.9.[67[. My setup is a Toshiba laptop
(satellite 4300) with stock redhat 7.1 (except the
kernel and mozilla of course).
I am sure that the kernel is crashed because it killed
all my telnet connections I had from other boxes. I
had set them up in order to kill X and/or mozilla but
the trick didn't work. Ping from other boxes however
did work.
To reproduce it:
-if you don't have a yahoo account create one
-mail me to send you the big (1MB) bad (spam) mail
that triggered the crash (total unresponsive system).
-try to open it from your account.
I am not subscribed to the list but I will read any
answers from the WWW archives.
Thank you for your time
.Bill
__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
^ permalink raw reply
* I2C Driver for MPC8xx
From: Pergola, Michael @ 2002-01-15 16:24 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
All,
I think I found a good I2C driver for the Embedded Planet MPC823e,
Dan Malek's i2c-algo-8xx.c. Has anyone successfully implemented this
on an EP platform?
TIA,
Michael Pergola
Baltimore, MD 21236 (410) 931-6778 x4259
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Problems with linuxppc_2_4_devel
From: Tom Rini @ 2002-01-15 16:25 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: linuxppc-dev@lists.linuxppc.org
In-Reply-To: <3C441EC6.8E192B49@switchboard.ericsson.se>
On Tue, Jan 15, 2002 at 01:21:26PM +0100, Kenneth Johansson wrote:
>
> I have some date problem BK think that we are at feb23 and that dose not look
> right when running revtool. Do anyone else see this or is it my clone?
>
>
> Also I get alot of "ERROR-cannot cd to linuxppc_2_4_devel" when running bk
> pull
What does:
$ bk parent
say (from your source tree)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: How to take a crash dump
From: Suparna Bhattacharya @ 2002-01-15 22:05 UTC (permalink / raw)
To: Erik Mouw; +Cc: SATHISH.J, linux-kernel, linux india programming
In-Reply-To: <20020114211408.GB21480@arthur.ubicom.tudelft.nl>
Erik Mouw wrote:
>
> On Fri, Jan 04, 2002 at 02:30:20PM +0530, SATHISH.J wrote:
> > I have "lcrash" installed on my system. I have 2.4.8 kernel. I would like
> > to know how to make a linux system panic so that I can take a crash dump
> > and analyse using "lcrash". Is there any command to make the system panis
> > as we have on other unices(SVR4 and unixware)?
>
Have you tried using the Alt+Sysrq+c key combination ?
We had checked in some changes to enable non-disruptive dumps to be
taken this way as
well (i.e. you can get a dump without having to reboot the system) but
that piece is going to be in lkcd 4.01.
BTW, you can also trigger a crash dump conditionally using dprobes.
Regards
Suparna
> I wrote a toy module that does exactly what you want:
>
> http://www.lart.tudelft.nl/lartware/port/lart.c
>
> I still have to get the module into Linus' tree so Christoph Hellwig
> will drive to .nl to buy me a beer :)
>
> Erik
>
> --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
> of Information Technology and Systems, Delft University of Technology,
> PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635
> Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl
> WWW: http://www-ict.its.tudelft.nl/~erik/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Linux-2.5.2
From: Paul Larson @ 2002-01-15 16:12 UTC (permalink / raw)
To: Alexander Viro; +Cc: Davide Libenzi, Linus Torvalds, Kernel Mailing List
In-Reply-To: <Pine.GSO.4.21.0201151107480.4339-100000@weyl.math.psu.edu>
On Tue, 15 Jan 2002, Alexander Viro wrote:
> ftp.math.psu.edu/pub/viro/LB38-fix-C2
>
This patch to fix the swapon not working in 2.5.2 seems to be working fine
on my machines.
Thanks Viro!
-Paul Larson
^ permalink raw reply
* Re: [BUG] symlink problem with knfsd and reiserfs
From: Hans-Peter Jansen @ 2002-01-15 16:31 UTC (permalink / raw)
To: Nikita Danilov, Trond Myklebust
Cc: Neil Brown, linux-kernel, Reiserfs mail-list, David L. Parsley
In-Reply-To: <15428.23828.941425.774587@laputa.namesys.com>
On Tuesday, 15. January 2002 17:47, Nikita Danilov wrote:
> Trond Myklebust writes:
> > On Tuesday 15. January 2002 16:27, Nikita Danilov wrote:
> > > In reiserfs there is no static inode table, so we keep global
> > > generation counter in a super block which is incremented on each inode
> > > deletion, this generation is stored in the new inodes. Not that good
> > > as per-inode generation, but we cannot do better without changing disk
> > > format.
> >
> > Am I right in assuming that you therefore cannot check that the
> > filehandle is stale if the client presents you with the filehandle of
> > the 'old' inode (prior to deletion)?
> > However if the client compares the 'old' and 'new' filehandle, it will
> > find them to be different?
>
> Sorry for being vague. Reiserfs keeps global "inode generation counter"
> ->s_inode_generation in a super block. This counter is incremented each
> time reiserfs inode is being deleted on a disk. When new inode is
> created, current value of ->s_inode_generation is stored in inode's
> on-disk representation. Inode number (objectid in reiserfs parlance) is
> reusable once inode was deleted. The same pair (i_ino, i_generation) can
> be assigned to different inode only after ->s_inode_generation
> overflows, which requires 2**32 file deletions.
Except it's in 3.5 format, which requires one deletion then?
> So, no, reiserfs can tell stale filehandle, although not as reliable as
> file systems with static inode tables.
>
> Hans-Peter, please tell me, what reiserfs format are you using. 3.5
> doesn't support NFS reliably. If you are using 3.5 you'll have to
> upgrade to 3.6 format (copy data to the new file system). mount -o conv
> will not eliminate this problem completely, but will make it much less
> probable, so you can try this first.
Bad luck for me, obviously :-(
<4>reiserfs: checking transaction log (device 03:09) ...
<4>Using r5 hash to sort names
<4>reiserfs: using 3.5.x disk format
<4>ReiserFS version 3.6.25
<4>reiserfs: checking transaction log (device 03:08) ...
<4>Using r5 hash to sort names
<4>reiserfs: using 3.5.x disk format
<4>ReiserFS version 3.6.25
<4>reiserfs: checking transaction log (device 03:06) ...
<4>Using r5 hash to sort names
<4>reiserfs: using 3.5.x disk format
<4>ReiserFS version 3.6.25
<4>reiserfs: checking transaction log (device 03:07) ...
<4>Using r5 hash to sort names
<4>reiserfs: using 3.5.x disk format
<4>ReiserFS version 3.6.25
<4>reiserfs: checking transaction log (device 03:0a) ...
<4>Using r5 hash to sort names
<4>reiserfs: using 3.5.x disk format
<4>ReiserFS version 3.6.25
<4>reiserfs: checking transaction log (device 21:02) ...
<4>Using r5 hash to sort names
<4>reiserfs: using 3.5.x disk format
<4>ReiserFS version 3.6.25
We're talking about 100 GB on _this_ server.
How big is the chance to loose data with -o conv?
Is there any paper around, which describes this conversion
a bit more detailed? If I understand you correctly, the inode
generation counter doesn't work at all with 3.5?
> > Cheers,
> > Trond
>
> Nikita.
Cheers,
Hans-Peter
^ permalink raw reply
* Re: Memory problem with bttv driver
From: Stephan von Krawczynski @ 2002-01-15 16:35 UTC (permalink / raw)
To: Gerd Knorr; +Cc: linux-kernel
In-Reply-To: <20020115161653.A9550@bytesex.org>
On Tue, 15 Jan 2002 16:16:53 +0100
Gerd Knorr <kraxel@bytesex.org> wrote:
> On Tue, Jan 15, 2002 at 02:46:52PM +0100, Stephan von Krawczynski wrote:
> > On Tue, 15 Jan 2002 14:20:17 +0100
> > Gerd Knorr <kraxel@bytesex.org> wrote:
> >
> > > Yes. Instead of remapping vmalloced kernel memory it gives you shared
> > > anonymous pages, then does zerocopy DMA using kiobufs. You may run in
> > > trouble with >4GB machines.
> >
> > Interesting.
> > What's the problem on > 4GB ?
>
> The bt878/848 is a 32bit PCI device, it simply can't go DMA to main
> memory above 4GB. At least on ia32, on architecures with a iommu
> (sparc, ...) it should work without trouble.
Sorry, maybe I should have clarified: what is the problem with allocating those
pages below 4GB in a >4GB box?
Regards,
Stephan
^ permalink raw reply
* New CRC32 fails to build
From: Russell King @ 2002-01-15 16:37 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
In 2.5.2, the new CRC stuff fails to build because the cleanup function
isn't marked with __exit:
/home/rmk/v2.5/linux-ebsa285/lib/lib.a(crc32.o): In function `cleanup_crc32':
crc32.o(.text+0x98): relocation truncated to fit: R_ARM_PC24 text.exit
crc32.o(.text+0x9c): relocation truncated to fit: R_ARM_PC24 text.exit
The following patch fixes the problem:
--- orig/lib/crc32.c Tue Jan 15 14:16:27 2002
+++ linux/lib/crc32.c Tue Jan 15 16:36:15 2002
@@ -558,7 +558,7 @@
/**
* cleanup_crc32(): frees crc32 data when no longer needed
*/
-static void cleanup_crc32(void)
+static void __exit cleanup_crc32(void)
{
crc32cleanup_le();
crc32cleanup_be();
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* Re: highmem=system killer, 2.2.17=performance killer ?
From: Klaus Meyer @ 2002-01-15 16:42 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: linux-kernel
In-Reply-To: <20020115160018.18793569.skraw@ithnet.com>
Stephan von Krawczynski wrote:
>
> On Tue, 15 Jan 2002 04:13:49 +0100
> Klaus Meyer <k.meyer@m3its.de> wrote:
>
> > i've got serious problems using 2.4.x kernels using highmem support.
> > It seems to me that i'm not the only one, but the difference to most
> > other ones is,
> > that i can't use highmem because the system performance is terrible
> > slow.
> >
> > the testbed:
> > 1) Asus CUR-DLS (Server Set LE III) with two 1Ghz Pentiums, 2GB of ram
>
> Interestingly I have about the same setup and use, only I transfer about 25 GB
> a day via nfs to an Asus CUV4XD with 2 GB under 2.4.18-pre3 and do not
> experience any problem so far. I haven't had any with 2.4.17, too. Cache is
> pretty heavy used, but I experience no slowdown or other weird things. Can this
> be somehow chipset related? Maybe something about the DGE cards? I am using TP
> 100MBit tulip-based.
>
I dont think that the network driver is the one who causes problems,
because the throughput is very nice, if i limit the memory to 1GB by
hand.
if files are in the cache I'm even getting a throughput of nearly 60
MB/S (using udp) !
(but sorry, not with kernel 2.2.17 => network throuput decreases
significantly)
The whole system is running quite stable and pretty fast using only 1GB
of mem.
Probably somebody can explain the difference what will happen if i have
a kernel
with highmem support (4GB or 64GB) compiled in, but using only 1GB of
physically 2GB?
Is the kernel aware how to use highmem in this case ?
it seems to be that only a small amount of highmem will be used in this
case:
cat /proc/meminfo reads:
HighTotal: 131072 kB
HighFree: 115628
kB
As I just took a look on the output of cat /proc/meminfo i got the idea
that i'll increase the pysical swap space. (136M before that means >
highmem).
astonishing (using Suse kernel 2.4.16): after an increase to 2GB swap
and
using 1,5GB of mem the system runs quit a longer time with a good
performance,
but starting the copy process leads also to a slow down of the machine.
Finally i could see that kupdated is suffering.
-----------------------------------------------------------------------------
5:56pm up 2 min, 1 user, load average: 2.97, 1.02, 0.36
34 processes: 29 sleeping, 5 running, 0 zombie, 0 stopped
CPU0 states: 2.5% user, 96.0% system, 0.0% nice, 1.0% idle
CPU1 states: 11.4% user, 95.0% system, 0.0% nice, -6.-5% idle
Mem: 1545456K av, 452480K used, 1092976K free, 0K shrd, 19708K
buff
Swap: 2097136K av, 0K used, 2097136K free 400732K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
7 root 15 0 0 0 0 RW 81.2 0.0 0:44
kupdated
------------------------------------------------------------------------------
As kupdated finished his work, the system was quite usefull and came
back to a
much more better performance.
Using the avail. 2 GB of ram led to the same effect.
So whats the relation between physical swap space and highmem and
physical memory
(and the chipset) ?
testing this configuration with the offical kernel 2.4.17 falls back to
the known slow down.
It seems to be Suse has applied some patches or back porting ?!?
regards, Klaus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.