* Re: IBM spamms me with error messages
From: Richard A Nelson @ 2002-12-11 16:53 UTC (permalink / raw)
To: kernel list
In-Reply-To: <200212110258.gBB2wXCb025160@badlands.lexington.ibm.com>
On Tue, 10 Dec 2002, David S. Miller wrote:
> Pavel, you're not the only person seeing this, and you're
> certainly not the only one sending emails to IBM's postmasters
> asking them to fix this.
>
> The lack of any response or actions by IBM's postmasters is certainly
> quite disturbing. Is there that much red tape at the company? :-)
At times, yes :(
I've not yet traced this fully, but it looks like it might be the RSCS
gateway in action - I'll try to get the relevant folks to look at it.
Unfortunately, there are several groups involved - AT&T handles the
exterior gateway servers, another group handles the Lotus gateways,
and I beleive a third does the ip->rscs(mainframe) gateway.
--
Rick Nelson
Now I know someone out there is going to claim, "Well then, UNIX is intuitive,
because you only need to learn 5000 commands, and then everything else follows
from that! Har har har!"
-- Andy Bates on "intuitive interfaces", slightly defending Macs
^ permalink raw reply
* SOFTWARE EXPORT UNIT
From: nesso nesso @ 2002-12-11 16:46 UTC (permalink / raw)
To: sonasos
Hi,
We are a software export unit based in Cochin Special Economic
Zone, INDIA.
Our unit is having brand new 70 Acer machine and 64 kb leased line
connectivity and all other basic infrastructure with export
license and other legal support.
We are looking for somebody having ready project and looking for a
unit with best infrastructure and license. We also support to form
the team according to the need of the project.
The benefit of using our unit is
No need of any infrastructure investments
Can start the project any moment.
Gentle terms and conditions
Support to make up the project team
Local media support if required.
24 hr electricity and water and security
Under ministry of commerce, GOVT. of INDIA.
Very close to Cochin International Air port
For more information,
Contact,
John Pius,
0091 484 395625/ 393921 or mobile 0091 98950 40468
mynacorp@sancharnet.in
Myna Corporation
2C, RDS Retreat,
Chittoor Road,
Kacheripady,
Kochin, Kerala, India
NB: if this message came to your mail box unnecessarily pls
reply message putting sub remove
^ permalink raw reply
* [PATCH] 2.5.51: Filesystem capabilities 0.12
From: Olaf Dietsche @ 2002-12-11 16:53 UTC (permalink / raw)
To: linux-kernel
This *untested* patch implements filesystem capabilities. It allows to
run privileged executables without the need for suid root.
Changes:
- updated to 2.5.51
- fixed deactivating fscaps at busy umount
This patch is available at:
<http://home.t-online.de/home/olaf.dietsche/linux/capability/>
Regards, Olaf.
^ permalink raw reply
* Re: Linux 2.4.21-pre1
From: Alan Cox @ 2002-12-11 17:29 UTC (permalink / raw)
To: Ralf Hildebrandt; +Cc: lkml, andre
In-Reply-To: <20021211155650.GU8741@charite.de>
Ok this seems to be the problem
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if
8a [Master SecP PriP])
Subsystem: Toshiba America Info Systems: Unknown device 0001
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
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at cff8 [size=8]
Region 1: I/O ports at cff4 [size=4]
Region 2: I/O ports at cfe8 [size=8]
Region 3: I/O ports at cfe4 [size=4]
The hardware isnt at the normal ide base addresse, yet the chip is
reporting that it isnt in native mode. As far as I can see this
configuration isnt allowed.
We see that the chip isnt in native mode so we defer to the legacy
scanner. Since the ports are not valid the legacy scanner doesn't find
them.
Any thoughts on how we should handle this case Andre ?
Alan
^ permalink raw reply
* Re: RE: FTP server access question
From: gerardo juarez-mondragon @ 2002-12-11 16:42 UTC (permalink / raw)
To: linuxask, linux-admin
Hi,
Option -M of smbclient allows you to send messages using the
"WinPopup" protocol to another computer.
Example:
cat message.txt | smbclient -M FRED
will send the message in the file "message.txt" to the machine
FRED.
I took it from the man page for smbclient. Check it, because there
are many more details.
Cheers,
Gerardo
PS - Is this Simon Shaw a real person? or just a name hiding a dozen
or so people asking questions? :-)
Searching for the best free email? Try MetaCrawler Mail, from the #1 metasearch service on the Web, http://www.metacrawler.com
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Martin Josefsson @ 2002-12-11 16:41 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: Netfilter mailinglist
In-Reply-To: <200212111701.39376.roy@karlsbakk.net>
On Wed, 2002-12-11 at 17:01, Roy Sigurd Karlsbakk wrote:
> seems like newnat-udp-helper.patch
> [root@fw linux]# patch -p1 <
> ../netfilter/patch-o-matic/pending/newnat-udp-helper.patch
> patching file include/linux/netfilter_ipv4/ip_nat_helper.h
> Hunk #1 succeeded at 36 (offset -14 lines).
> patching file net/ipv4/netfilter/ip_nat_helper.c
> Hunk #1 FAILED at 8.
> Hunk #2 succeeded at 18 (offset -7 lines).
> Hunk #3 succeeded at 53 (offset -2 lines).
> Hunk #4 succeeded at 75 (offset -7 lines).
> Hunk #5 succeeded at 174 (offset -2 lines).
> Hunk #6 succeeded at 203 with fuzz 2 (offset -7 lines).
> 1 out of 6 hunks FAILED -- saving rejects to file
> net/ipv4/netfilter/ip_nat_helper.c.rej
> patching file net/ipv4/netfilter/ip_nat_standalone.c
> Hunk #1 FAILED at 358.
> 1 out of 1 hunk FAILED -- saving rejects to file
> net/ipv4/netfilter/ip_nat_standalone.c.rej
This patch applies fine here after applying the other submitted patches
first.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
^ permalink raw reply
* RE: [ACPI] Dell i8k was: Re: [2.5.50, ACPI] link error
From: Moore, Robert @ 2002-12-11 16:40 UTC (permalink / raw)
To: 'Andrew McGregor', Pavel Machek, Alan Cox
Cc: Grover, Andrew, 'Ducrot Bruno', Ducrot Bruno,
Patrick Mochel, Linux Kernel Mailing List, ACPI mailing list
The problem is related to this message:
ACPI-0189: *** Warning: Buffer created with zero length in AML
I have a patch for the oops caused by this, but there may be an additional
underlying problem where the AML is causing a zero length buffer to be
created.
Bob
-----Original Message-----
From: Andrew McGregor [mailto:andrew-Rd3uoDiDeHXJKwlM9GxbOw@public.gmane.org]
Sent: Tuesday, December 10, 2002 7:45 PM
To: Pavel Machek; Alan Cox
Cc: Grover, Andrew; 'Ducrot Bruno'; Ducrot Bruno; Patrick Mochel; Linux
Kernel Mailing List; ACPI mailing list
Subject: Re: [ACPI] Dell i8k was: Re: [2.5.50, ACPI] link error
Hmm, when I boot 2.5.51 w/ACPI on it with a battery installed, it panics.
By booting without and then inserting the battery, I got the attached oops.
See also the messages in the dmesg output.
Andrew
--On Wednesday, December 11, 2002 09:50:48 +1300 Andrew McGregor
<andrew-Rd3uoDiDeHXJKwlM9GxbOw@public.gmane.org> wrote:
> I strongly suspect that s4bios will work on this machine, but swsusp
> won't. Why? It's a Dell Inspiron 8000 with an NVidia Geforce2go, and
> until NVidia put pm support in their driver, it's game over for Linux.
> Except that the BIOS knows how to suspend it, so some kernel/driver
> combinations work with APM. I suspect any Geforce2go Dell is the same.
>
> Andrew
>
> --On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek
> <pavel-AlSwsSmVLrQ@public.gmane.org> wrote:
>
>> Hi!
>>
>>> > I concur with your pros and cons. This makes me think that if S4BIOS
>>> > support ever gets added, it should get added to 2.4 only.
>>
>> And S4BIOS will never get added to 2.4 since it needs driver model
>> :-(.
>>
>>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>>> bad tables or "knowing" what other-os does)
>>
>> We have full control over S4 (== swsusp), so we can fix that in most
>> cases.
>>
>> S4BIOS is still little friendlier to the user -- no need to set up
>> swap partition and command line parameter, can't go wrong if you boot
>> without resume=, etc.
>> Pavel
>>
>> --
>> Casualities in World Trade Center: ~3k dead inside the building,
>> cryptography in U.S.A. and free speech in Czech Republic.
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>> in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.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: [2.4]ALi M5451 sound hangs on init; workaround
From: Alan Cox @ 2002-12-11 16:35 UTC (permalink / raw)
To: Fedor Karpelevitch; +Cc: lkml, Vicente Aguilar, alsa-devel, Debian-Laptops
In-Reply-To: <200212110715.20617.fedor@apache.org>
On Wed, 2002-12-11 at 15:15, Fedor Karpelevitch wrote:
> (currently 2.4.20-ac1 + hirofumi patch). I traced it down to the line
> where it hangs - that is drivers/sound/trident.c:3379 which says:
> pci_write_config_byte(pci_dev, 0xB8, ~temp);
>
> removing this line fixes the problem for me.
> I am not sure what would be the proper fix
Thats a big clue. ATI haven't released docs for the Radeon IGP so
support is minimal and very much 'done the hard way'. I do have ALi docs
however which may help.
^ permalink raw reply
* [PATCH] 2.5.51: access permission filesystem 0.12
From: Olaf Dietsche @ 2002-12-11 16:43 UTC (permalink / raw)
To: linux-kernel
This *untested* patch adds a new permission managing file system.
Furthermore, it adds two modules, which make use of this file system.
One module allows granting capabilities based on user-/groupid. The
second module allows to grant access to lower numbered ports based on
user-/groupid, too.
Changes:
- updated to 2.5.51
- removed fill_empty_from(), now done by security_fixup_ops()
This patch is available at:
<http://home.t-online.de/home/olaf.dietsche/linux/accessfs/>
Regards, Olaf.
^ permalink raw reply
* Re: Modifying Source Ip on input/prerouting
From: Andrea Rossato @ 2002-12-11 16:34 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20021211153854.GA9333@nath.rubis.org>
Stephane Jourdois wrote:
> The problem is that I wan't to change the incoming traffic...
> What I would need is something similar to :
> -A PREROUTING -j SNAT --from-source xxx
what you need is probably
iptables -A OUTPUT -t nat -j DNAT --to 1.2.3.4
iptables tutorial says that output chain in nat table is broken. but i
don't know if it still is.
andrea
^ permalink raw reply
* RE: [ACPI] Dell i8k was: Re: [2.5.50, ACPI] link error
From: Moore, Robert @ 2002-12-11 16:40 UTC (permalink / raw)
To: 'Andrew McGregor', Pavel Machek, Alan Cox
Cc: Grover, Andrew, 'Ducrot Bruno', Ducrot Bruno,
Patrick Mochel, Linux Kernel Mailing List, ACPI mailing list
The problem is related to this message:
ACPI-0189: *** Warning: Buffer created with zero length in AML
I have a patch for the oops caused by this, but there may be an additional
underlying problem where the AML is causing a zero length buffer to be
created.
Bob
-----Original Message-----
From: Andrew McGregor [mailto:andrew@indranet.co.nz]
Sent: Tuesday, December 10, 2002 7:45 PM
To: Pavel Machek; Alan Cox
Cc: Grover, Andrew; 'Ducrot Bruno'; Ducrot Bruno; Patrick Mochel; Linux
Kernel Mailing List; ACPI mailing list
Subject: Re: [ACPI] Dell i8k was: Re: [2.5.50, ACPI] link error
Hmm, when I boot 2.5.51 w/ACPI on it with a battery installed, it panics.
By booting without and then inserting the battery, I got the attached oops.
See also the messages in the dmesg output.
Andrew
--On Wednesday, December 11, 2002 09:50:48 +1300 Andrew McGregor
<andrew@indranet.co.nz> wrote:
> I strongly suspect that s4bios will work on this machine, but swsusp
> won't. Why? It's a Dell Inspiron 8000 with an NVidia Geforce2go, and
> until NVidia put pm support in their driver, it's game over for Linux.
> Except that the BIOS knows how to suspend it, so some kernel/driver
> combinations work with APM. I suspect any Geforce2go Dell is the same.
>
> Andrew
>
> --On Tuesday, December 10, 2002 21:40:31 +0100 Pavel Machek
> <pavel@suse.cz> wrote:
>
>> Hi!
>>
>>> > I concur with your pros and cons. This makes me think that if S4BIOS
>>> > support ever gets added, it should get added to 2.4 only.
>>
>> And S4BIOS will never get added to 2.4 since it needs driver model
>> :-(.
>>
>>> That assumes no box exists where S4bios works an S4 doesnt (eg due to
>>> bad tables or "knowing" what other-os does)
>>
>> We have full control over S4 (== swsusp), so we can fix that in most
>> cases.
>>
>> S4BIOS is still little friendlier to the user -- no need to set up
>> swap partition and command line parameter, can't go wrong if you boot
>> without resume=, etc.
>> Pavel
>>
>> --
>> Casualities in World Trade Center: ~3k dead inside the building,
>> cryptography in U.S.A. and free speech in Czech Republic.
>> -
>> 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/
>>
>>
>
>
> -
> 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
* mixer controls for bass/treble in emu10k driver
From: jordan.breeding @ 2002-12-11 16:31 UTC (permalink / raw)
To: alsa-devel
Is it possible for the emu10k (SBLive!/Audigy) driver to get bass/treble
mixer controls in ALSA like it has in Windows and the OSS Linux (when you load
the right file with the emu10k tools) driver? Thanks.
Jordan
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Christoph Hellwig @ 2002-12-11 16:23 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: James Bottomley, linux-scsi
In-Reply-To: <1313340000.1039622906@aslan.scsiguy.com>
On Wed, Dec 11, 2002 at 09:08:26AM -0700, Justin T. Gibbs wrote:
> >> Why is this based on Alpha1 and not Alpha2.
> >
> > Because that's a) what James put in the BK tree and b) that's what I
> > downloaded from your website today for reference.
>
> Where did you download it from. This file is Alpha2 based:
>
> http://people.FreeBSD.org/~gibbs/linux/SRC/aic79xx-linux-2.5.tar.gz
Yes, from exactly that location. But it seems like a broken proxy cached
the old version, I've downloaded it on another host now and it's uptodate.
> >> driver has to build all the way back to 2.4.7 (RedHat 7.2 support).
> >
> > RedHat only supports kernel 2.4.18 for RH7.2/i386 and 2.4.9 with tons of
> > hacks for the other arches, so your argument is void.
>
> Tell that to the OEMs that Adaptec has to support. They still test and
> require 7.2 drivers.
RedHat's current, supported kernels for RHL7.2 are 2.4.18-18.7.x (i386),
2.4.9-40 (ia64) and 2.4.9-38 (s390, but that one doesn't support pci
scsi cards anyway..).
> I have no problem with interfaces changing for good reason, but, for
> example,
> a driver that alread sets unchecked_isa_dma to 0 and uses the PCI dma mask
> shouldn't have to set addition flags (with different names in different
> vendor's trees) to enable HIGHIO. It's yet-another *stupid* interface
> change.
Maybe you could have complained about that more than one year ago when the
patch came up first?
> > Interestingly only vendor driver use that shitty scheme.
>
> Yes, because the vendor actually has to support all of those versions
> unlike some guy who hacks this stuff in his spare time and could care
> less about anyone else's requirements but his own.
Umm, if you would properly feed your patches upstream vendors could include
current versions easily and there would be no need for extra applied patches.
It's pretty simple. If on the other hand the vendor thinks he should
support every stupid RedHat and SuSE release (and it really hurts to see
what these companies do to their release kernels) it's their problem. But
having all those ifdefs in the source in mainline is horribly ugly. Note
that there are a few drivers that properly use the newest API and use
a compat header to map it to older interface on older kernels (that's not
always possible for scsi because the interface is still to crappy to keep it,
I hope that will change once 2.6 is done).
Okay, let's stop that discussion that doesn't bring us forward anyway,
and try to get your changes in the mainline kernel. I'll merge your
new driver into the BK tree where I did the other work and send your the full
diff to your release. IT would be nice if you could submit small
incremental diffs for each new release after that, okay?
^ permalink raw reply
* Re: Is this going to be true ?
From: Richard B. Johnson @ 2002-12-11 16:33 UTC (permalink / raw)
To: Måns Rullgård; +Cc: Herman Oosthuysen, linux-kernel
In-Reply-To: <yw1xbs3smtx0.fsf@gladiusit.e.kth.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 1581 bytes --]
On 11 Dec 2002, [iso-8859-1] Måns Rullgård wrote:
> Herman Oosthuysen <Herman@WirelessNetworksInc.com> writes:
>
> > MS history shows that they did and does support various flavours of
> > *nix. So, it is not beneath them to release apps for Linux too one
> > day and it would be a good thing if they do.
>
> Why would that be good? People would start using their programs and
> blame Linux when they crash.
Well, when the program crashes, you get to run it again under Linux
and Unix operating systems. Not so with Windows. With Windows, you
reinstall windows after first booting DOS from a floppy and using
DEBUG to clear out the partition information, otherwise the new
Windows installation won't boot. Microsoft "help" desk advises to
replace the disk when, in fact, the partition information has been
corrupted by Windows.
>
> > Competition is always good. It inpires people to do better.
>
> Doing better than MS isn't much of an inspiration to me.
>
Competition isn't always good. There are people in the former
Soviet Union and in India who will gladly do your job. And, they
will do it just as well as you, perhaps even better. You get to
live where you have your own bathroom, but can't afford hot water
because you don't have a job. The people who now do your job
never had it so good. They have hot water for the first time in
their lives.
So, competition simply changes who has hot water.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* My first usb storage automount script :)
From: Wout Mertens @ 2002-12-11 16:22 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1612 bytes --]
Hi there,
I just wanted to share what I hacked up through some frustration. It's a
script that will automatically mount usb devices that are attached.
It ties in to the hotplug architecture as closely as possible, without
changing anything. So then I subscribed to this list to announce it.
Of course, that's when I discovered
http://users.actrix.co.nz/michael/usbmount.html by Michael Hamilton.
So I'll first give a rundown of differences:
My solution:
- only mounts the device that was just inserted (with some luck)
- is called automount_usb, so that, by changing the usb.usermap, it gets
called every time a device is inserted and not just the first time
- creates remover scripts that have /bin/sh as the only dependency
- creates nicely readable names as mount points
- supports devices with multiple partitions
- is really small
But Michael's solution:
- makes KDE icons
- is easier to read
So, please have a look at the attached code, and tell me what you think
about the device detection code. Michael, if you read this, we could
perhaps merge the two efforts and get all the features.
Also, let's start a thread on making a gui.agent script that gets called
by the hotplug scripts. It would notify the user of hotplug events.
I feel that it should be called with the same environment as the other
agents, with an extra HOTPLUG_PATH variable indicating the path on which
the device is available, if applicable.
This could then be used by KDE, Gnome etc to notify the user.
Cheers,
Wout.
PS: /Please/ change usb.agent so that it creates /var/run/usb/ before
pointing remover scripts there...
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2996 bytes --]
#!/bin/sh
# Automount hotplugged usb storage devices. Copyright (c) 2002, Wout Mertens
# This script is released under the GPL.
# The usb devices will be mounted for the console user.
# To work, this needs:
# - kernel support:
# - hotplugging, /proc, usbdevfs and devfs
# - as modules: usb-storage, sd_mod, scsi_mod
# - filesystems that will be mounted, like vfat
# - ls, tr, echo, awk, basename, stat, grep, mount, umount, mkdir, rm, sed
# TODO Fix usb.agent so that /var/run/usb gets created if missing
# TODO Some rigid way of getting this run. Currently, I do
# grep usb-storage /lib/modules/*/modules.usbmap|sed 's/usb-storage/automount_usb/' >> /etc/hotplug/usb.usermap
# TODO Lots of testing
# TODO nice way of setting options
# TODO Also, the error checking should probably be more robust
# TODO Some clean way of handling disconnects while writing.
# TODO Make a generic event system for GUIs that shows that something was
# mounted for the user. Proposal: /etc/hotplug/gui.agent gets
# called with ACTION=add/remove, NAME=nice_name, PATH=new_path, etc.
# Not just for new storage, scanners and so on are useful too...
# Dump debug
mesg () {
#return
/usr/bin/logger -t $0 "$*"
}
# Figure out the device to mount
NUM=`basename $DEVICE|sed 's/^0*//'`
SERIAL=`awk -F= '/^T:.*/{if($0~/Dev#= *'$NUM' /){t=1}else{t=0}}t==1&&/SerialNumber/{print $2;exit}' /proc/bus/usb/devices`
PRODUCT=`awk -F= '/^T:.*/{if($0~/Dev#= *'$NUM' /){t=1}else{t=0}}t==1&&/Product/{print $2;exit}' /proc/bus/usb/devices`
# Use the serial or the product name to find which scsi host was just created
if [ -n "$SERIAL" ]; then
SCSI=`grep -l $SERIAL /proc/scsi/usb-storage-*/*|tail -1`
elif [ -n "$PRODUCT" ]; then
SCSI=`grep -l $PRODUCT /proc/scsi/usb-storage-*/*|tail -1`
fi
mesg Device No. $NUM, serial $SERIAL, name $PRODUCT, path $SCSI
# Mount it
if [ -n "$SCSI" ]; then
# The name of the file is the number of the SCSI host
SCSI=`basename $SCSI`
PARTS=`ls /dev/scsi/host$SCSI/*/*/*/part*`
MOUNTPATH=/mnt/usb/`echo $PRODUCT|tr '[ /?*"]' _`
if [ -e "$MOUNTPATH" ]; then
if mount|grep "$MOUNTPATH">/dev/null; then
# TODO I'm too lazy to write proper collision avoidance code
MOUNTPATH="$MOUNTPATH".$$
fi
fi
# I'm hoping that mount ignores options that don't apply to the fs
# These options should prevent abuse and make it writeable for the
# console user.
MOUNTOPTS='-osync,nosuid'`stat -c',uid=%u,gid=%g' /dev/console`
mesg Mounting $PARTS on $MOUNTPATH, options $MOUNTOPTS
[ `echo $PARTS|wc -w` -eq 1 ] && MOUNTDIRECT=1
REMOVE=
for i in $PARTS; do
if [ -n "$MOUNTDIRECT" ]; then
T=$MOUNTPATH
else
T=$MOUNTPATH/`basename $i`
fi
mkdir -p $T
if mount $MOUNTOPTS $i $T; then
REMOVE="umount $T;$REMOVE;rmdir $T"
else
rmdir $T
fi
done
# Create remover
echo "#!/bin/sh" > $REMOVER
echo $REMOVE | sed 's/;;/;/g' >> $REMOVER
chmod +x $REMOVER
else
exit 1
fi
^ permalink raw reply
* SGI INDY and RedHat
From: Carlos Vieira @ 2002-12-11 17:53 UTC (permalink / raw)
To: linux-mips
Hi,
I have an SGI Indy with R5000 MIPS processor
and with IRIX OS.
I want to make this machine a DNS Server with
RedHat for MIPS processor.
How can i install RedHat in this machine without
using IRIX that is installed.
Netboot at machine boot time is a good option (using bootp server
for downloading kernel and then get the rest of the
OS installation)?
Thanks in advance
Carlos
^ permalink raw reply
* Re: Reliable hardware
From: John Bradford @ 2002-12-11 16:33 UTC (permalink / raw)
To: Orion Poplawski; +Cc: scott, alan, linux-kernel
In-Reply-To: <3DF76302.7040503@cora.nwra.com>
> >>Random lockups on dual athlons are a notorious problem under all
> >>OS's. Start by checking it passes memtest86, that will verify the
> >>RAM is ok - and the AMD is -very- picky about RAM.
> >>
> >>If thats ok then let me know which board you have, what is plugged
> >>into it and what PSU you are using.
> >>
> >>
> >
> >I have two AMD MP 2000+ cpus in an ASUS A7M266-D. Even after returning
> >my memory for new chips the store owner memtest86'd, my combo of cpus
> >and mobo was finding the occasional error. I finally ended up
> >resolving it by simply underclocking the bus about 6Mhz :(
> >
> >Next time, I'm buying ECC memory.
Why? ECC memory guards against a single bit error in the RAM, nothing
else, (except that it also reports double bit errors).
John.
^ permalink raw reply
* RE: [RFC] countdown timer driver
From: Heater, Daniel (IndSys, GEFanuc, VMIC) @ 2002-12-11 16:25 UTC (permalink / raw)
To: 'george anzinger', Dan Kegel
Cc: Heater, Daniel (IndSys, GEFanuc, VMIC), linux-kernel
> >
> > > Questions:
> > > 1. Is there already a standard kernel interface to this
> type of timer?
> >
> > The Posix high-res timer stuff, I think. Have you tried expressing
> > what you want user programs to do in terms of Posix
> high-res timers yet?
> >
> > > 2. Is there any reason to interface/integrate this type
> of device with the
> > > high-res timer stuff currently under development for
> the 2.5 kernel?
> >
> > Yes; perhaps you could create a service provider interface
> > for the posix high-res timer stuff, then use that SPI
> > to plug your hardware in?
> >
> > I may be way off base here, but it does seem like it's due
> dilligence
> > to verify that you're not reinventing an interface here.
> > - Dan
> >
> Let me help out here if I may. First, not to rain on your
> parade but, when I did high-res timers on another system,
> far away and long ago, we dropped support for the hardware
> timers. I.e. I would submit that the POSIX timers interface
> to a common system timer does all you need and more.
I suspect that is most often the case. My task, working for an OEM,
is to provide access to the available hardware. The customer's decide
if the hardware is appropriate to their needs, and still many customers
are demanding access to these devices. I am going to try to do a study
on whether additional hardware timers are of any benefit given the
resources available on current standard hardware and the availability of
the high-res patch, but the additional hardware is probably still going
to be available because it is needed on others OS's.
> You MAY want to consider using your hardware as the system clock
> underlying jiffies and all the system timers, but that is
> another issue.
>
> You also may want to define a new CLOCK for the POSIX
> timers. Most of this capability is in place in the current
> patch. I did notice, however, that I took a short cut on
> the clock_nanosleep code and assumed that it was a standard
> clock. This is easy to change... The new CLOCK(s) would
> then talk to your hardware. The problem you will encounter,
> and which the high-res-patch solves, is making the timers
> available to all comers, i.e. there is no reservation system
> or busy counter, etc. Just a nice set timer and give me a
> signal when it is done.
>
Hmmm, that sounds promising.
> You can code a blocking interface using the sigwait and
> friends calls which will also cut down of the timer delivery
> overhead by eliminating the signal.
Very good.
> So what more could you ask for?
I've already sent Santa my list.
Thanks for the advice.
^ permalink raw reply
* Re: Reliable hardware
From: Alan Cox @ 2002-12-11 17:01 UTC (permalink / raw)
To: Orion Poplawski; +Cc: scott, Linux Kernel Mailing List
In-Reply-To: <3DF76302.7040503@cora.nwra.com>
On Wed, 2002-12-11 at 16:08, Orion Poplawski wrote:
> Is there a good site for pointers towards assembling reliable Linux
> machines? It seems to me the trickiest part of the whole operation is
> choosing good hardware in the first place. I just started a new job and
> inherited a buch of new but flakey machines, and I'd like to avoid doing
> that in the future.
The AMD duals have been a disaster in my experience. Its a shame because
when they do go they really are very fast boxes. The biggest factor I've
found is chipsets.
^ permalink raw reply
* Re: problem about CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID ?
From: Roger Gammans @ 2002-12-11 16:22 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Hu, Boris, Linux Kernel ML (E-mail), NPTL list (E-mail)
In-Reply-To: <3DF63A0C.6010708@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
On Tue, Dec 10, 2002 at 11:01:32AM -0800, Ulrich Drepper wrote:
> Hu, Boris wrote:
>
> > I have searched CLONE_PARENT_SETTID in kernel, it seems only to appear in
> > some non-architecture files, such as /include/linux/sched.h and several arch
> [snip]
> the kernel. Nobody cared for Arm so far so there obviously is no kernel
> support.
Unless Russell has changed his mind recently,[1] use of SWP in userspace code
isn't supported.
I suppose this is less of a concern if futex's work on ARM though.
But you'll need some userspace synchronisation primitive to do useful work
with threads.
TTFN
[1] And I haven't been following linux-arm recently.
--
Roger.
Master of Peng Shui. (Ancient oriental art of Penguin Arranging)
GPG Key FPR: CFF1 F383 F854 4E6A 918D 5CFF A90D E73B 88DE 0B3E
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* perfctr-2.4.3 released
From: Mikael Pettersson @ 2002-12-11 16:21 UTC (permalink / raw)
To: perfctr-devel; +Cc: linux-kernel
perfctr-2.4.3 is now available at the usual place:
http://www.csd.uu.se/~mikpe/linux/perfctr/
Users of hyper-threaded Pentium 4s (Xeons) are strongly
recommended to upgrade to this release. Older releases
may silently malfunction due to the resource conflicts
mentioned in the CHANGES extract below.
Version 2.4.3, 2002-12-11
- Support for hyper-threaded Pentium 4s added. In a HT P4, the
two logical processors share the performance counter state.
HT P4s are therefore _asymmetric_ multi-processors, and the
driver enforces CPU affinity masks on users of per-process
performance counters to avoid resource conflicts. (Users are
restricted to logical processor #0 in each physical CPU.)
Limitations:
* The kernel mechanism for updating a process' CPU affinity
mask uses no or very weak locking, which makes certain race
conditions possible that can break the driver's CPU affinity
mask restrictions. For now, users should NOT use the
sched_setaffinity() system call on processes using per-process
performance counters.
* Global-mode performance counters don't work on HT P4s due to
limitations in the API. This will be fixed in perfctr-2.5.
* 2.2 kernels don't have CPU affinity masks, and therefore can't
support HT P4s.
/ Mikael Pettersson
^ permalink raw reply
* Re: hidden interface (ARP) 2.4.20
From: Bill Davidsen @ 2002-12-11 16:15 UTC (permalink / raw)
To: Roberto Nibali; +Cc: 'linux-kernel@vger.kernel.org', linux-net
In-Reply-To: <3DF62F2F.3030805@drugphish.ch>
On Tue, 10 Dec 2002, Roberto Nibali wrote:
> > I have in mid multiple ISPs for redundancy, perhaps a pair of OC12s or
> > similar. Sites would be reachable from either, but fewer hops to one or
> > the other. When the client connects, it avoids asymmetric routing to reply
> > on the same router.
>
> I understand everything but the last sentence. You have a couple of
> redundant ISP links which can all act as a router to the Internet, the
> only difference is that if you go over some of them you need less hops.
> Now in order to avoid asymmetric routing you need the hidden patch? I
> apologise for being so narrow minded but I still don't get it.
Don't. You are right about this one, a client originated connection will
have an ARP entry and route back by the original route. Connections
originated on the dual-homed system might put a packet out on either NIC,
from any IP, that's a different issue, and the whole hidden interface
patch really doesn't address it.
I was mixing things from two problems I've seen, sorry for any confusion.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Roy Sigurd Karlsbakk @ 2002-12-11 16:09 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter mailinglist
In-Reply-To: <1039621206.20499.86.camel@tux>
On Wednesday 11 December 2002 16:40, Martin Josefsson wrote:
> On Wed, 2002-12-11 at 16:35, Roy Sigurd Karlsbakk wrote:
> > that's exactly what I'm doing. with kernel 2.4.19 and 2.4.20.
> > doesn't work
> > so.
> > can I just add the required patches manually without going for the whole
> > bunch?
> > if so - which ones do i need?
>
> You will at least need the newnat patch. (I hope the pptp patch doesn't
> depend on some other patch in there)
> But everything in the pending directory is recommended.
>
> then just apply the pptp patch.
>
> I can't see why this shouldn't work for you.
> You are sure you are using an up to date cvs checkout?
ok.
testing with 2.4.20:
# rm -rf linux-2.4.19 && \
tar xzf packed/linux-2.4.19.tar.gz && \
cd linux-2.4.19 && \
zcat ../packed/patch-2.4.20.gz | patch -p1 && \
cd ../netfilter/patch-o-matic && \
cvs update -Pd -D now && \
./runme pending
...
Testing... ip_conntrack_protocol_destroy.patch NOT APPLIED (6 rejects out of 6
hunks)
Testing... remove_no_version.patch NOT APPLIED (4 rejects out of 4 hunks)
Testing... newnat-udp-helper.patch NOT APPLIED (8 rejects out of 8 hunks)
...
# patch -p1 < /usr/src/netfilter/patch-o-matic/extra/pptp-conntrack-nat.patch
patching file include/linux/netfilter_ipv4/ip_conntrack_pptp.h
patching file include/linux/netfilter_ipv4/ip_conntrack_proto_gre.h
patching file include/linux/netfilter_ipv4/ip_conntrack_tuple.h
patching file include/linux/netfilter_ipv4/ip_nat_pptp.h
patching file net/ipv4/netfilter/ip_conntrack_core.c
Hunk #1 succeeded at 144 (offset 4 lines).
Hunk #3 succeeded at 941 with fuzz 2 (offset 75 lines).
Hunk #4 succeeded at 994 (offset 18 lines).
patching file net/ipv4/netfilter/ip_conntrack_pptp.c
patching file net/ipv4/netfilter/ip_conntrack_pptp_priv.h
patching file net/ipv4/netfilter/ip_conntrack_proto_gre.c
patching file net/ipv4/netfilter/ip_nat_core.c
Hunk #1 succeeded at 434 (offset 2 lines).
patching file net/ipv4/netfilter/ip_nat_pptp.c
patching file net/ipv4/netfilter/ip_nat_proto_gre.c
patching file net/ipv4/netfilter/Config.in
Hunk #1 succeeded at 77 (offset 9 lines).
patching file net/ipv4/netfilter/Makefile
Hunk #1 succeeded at 31 with fuzz 2.
#
...but it's not there
how do I patch manually?
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-11 16:08 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: James Bottomley, linux-scsi
In-Reply-To: <20021211153935.A23704@infradead.org>
>> Why is this based on Alpha1 and not Alpha2.
>
> Because that's a) what James put in the BK tree and b) that's what I
> downloaded from your website today for reference.
Where did you download it from. This file is Alpha2 based:
http://people.FreeBSD.org/~gibbs/linux/SRC/aic79xx-linux-2.5.tar.gz
>> driver has to build all the way back to 2.4.7 (RedHat 7.2 support).
>
> RedHat only supports kernel 2.4.18 for RH7.2/i386 and 2.4.9 with tons of
> hacks for the other arches, so your argument is void.
Tell that to the OEMs that Adaptec has to support. They still test and
require 7.2 drivers.
> Not to mention the
> only support that is dropped by my changes is for builtin support <
> 2.2.18.
I'll have to verify that.
>> Removing ifdefs just makes it harder for me to merge in changes from
>> external trees. Yes, the ifdefs are ugly, but so is the Linux SCSI layer
>> and the unmanaged way that interfaces have been changed without any
>> consideration to backwards compatibility (eg. the HIGHIO stuff could have
>> been done with 0 impact to drivers, but wasn't for some strange reason).
>
> linux driver interface change between stable series, face it.
I have no problem with interfaces changing for good reason, but, for
example,
a driver that alread sets unchecked_isa_dma to 0 and uses the PCI dma mask
shouldn't have to set addition flags (with different names in different
vendor's trees) to enable HIGHIO. It's yet-another *stupid* interface
change.
> And a driver with tons of ifdefs is utter crap.
I agree with that, but since we have to build for something like 35
different
kernel versions (major vendor releases plus all of their errata), there is
not much choice as a vendor. Without the ifdefs, one of those builds
invariably gets broken by a minor driver update because the person doing
the update doesn't understand how their change will effect the support for
the other kernels.
> Interestingly only vendor driver use that shitty scheme.
Yes, because the vendor actually has to support all of those versions
unlike some guy who hacks this stuff in his spare time and could care
less about anyone else's requirements but his own. So your choice becomes
either accept the ifdefs so that the vendor can sell its products by meeting
OEM/Channel demands, or have the vendor exit the Linux market and not even
attempt to support their product.
--
Justin
^ permalink raw reply
* Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).
From: Miles Lane @ 2002-12-11 16:05 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Linux Fbdev development list
In-Reply-To: <1039610250.1147.95.camel@localhost.localdomain>
On Wed, 2002-12-11 at 04:49, Antonino Daplas wrote:
> On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> > Hi,
> >
> > I have tried getting rivafb to work in 2.5.51. It is much better
> > than before (thanks!). It compiles and sorta works.
> >
> > Here are the problems:
> >
> > When I run "fbset -a 640x480", I get display that fills
> > the screen and looks okay, but most of the characters are
> > flipped along the vertical axis, so they are backwards, so that:
> >
> > +---- ----+
> > | |
> > +--- becomes ---+
> > | |
> > | |
> >
> What's the hardware, is it on a big endian machine? I think there's a
> typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN). This should
> produce the "mirroring" effect.
CPU: AMD Athlon(tm) Processor stepping 01
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller (rev 25)
01:05.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256
DDR] (rev 10) (prog-if 00 [VGA])
Subsystem: VISIONTEK: Unknown device 000b
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: 64 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fd000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at feaf0000 [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
> Secondly, a lot of the changes there are for riva128, which may not
> apply for all cards. Try doing fbset -accel false/true and see if
> there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
> and comment out the line with the FB_ACCELF_TEXT. This should force the
> hardware to do everything in software.
Thanks, I'll check this today.
Miles
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ 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.