[Marc Mutz [EMAIL PROTECTED]]
Should that not be first converted to paths that contain no symlinks?
I agree.
--- Makefile~ Tue Nov 28 21:53:31 2000
+++ MakefileFri Dec 1 12:25:28 2000
@@ -10,7 +10,7 @@
CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
else if [
Ivan,
I have tried test12-pre3 with and without your patch, it fails in the same
way.
The Qlogic SCSI controller continues to fail if we have 1 gig in the machine.
(But works fine without it.)
Any ideas? (Or patches that I can test... ;-) )
Thanks,
--Phil
Compaq: High Performance Server
I've had second-hand reports of an issue with ACPI and cardbus, but I
haven't enough about this to actually diagnose the problem.
Is anyone experiencing this?
If so, could you please provide some more details to me, so we can get this
fixed ASAP?
Thanks -- Regards -- Andy
With 2.4.0-test11, when ip_no_pmtu_disc is still 0/false we're seeing
outbound udp packets with the IP DF bit set. Is this change in default
behavior a fix or a break?
Its a change in behaviour
So, it appears that 2.4 fixed a problem with 2.2, correct?
[stop non expert thinking]
2.2
Peter Samuelson wrote:
snip
+TOPDIR := $(shell pwd -P)
snip
That is specific to the bash builtin 'pwd'. GNU sh-util's pwd does not
know that option (at least not my version, which is: "pwd (GNU sh-utils)
1.16")
I just wanted to note that...
Marc
--
Marc Mutz [EMAIL PROTECTED]
I've followed the thread on "Persistent module
storage" but haven't come across a general explanation
of the changes to the inter-module symbol stuff
between 2.4test10 and test11. Anyone care to comment
on the differences or on whether this is going to be a
stable API for 2.4 (it won't be
Hi,
On Tue, Nov 21, 2000 at 11:18:15AM -0500, Eric Lowe wrote:
I have updated raw I/O patches with Andrea's and my fixes against 2.2.
They check for CONFIG_BIGMEM so they can be applied and compiled
without the bigmem patch.
I've just posted an assembly of all of the outstanding raw IO
I've got a motherboard with the same Via686a chipset, and i've never had a
problem with DMA when it's enabled.
Using a pair of 20 gig IBM drives on the secondary, and a 3.2 quantum primary,
17.2 gig maxtor. All using DMA, all work. Using ultra/33, I wasn't even
aware this chipset is ultra/66
On Fri, 1 Dec 2000, Alan Cox wrote:
Intel PXE uses tftp to download boot images and discards IP packets with
the DF bit set; so a tftpd server on 2.4 with the default
Then Intel PXE is buggy and you should go spank whoever provided
it as well as doing the workarounds. Supporting received
Alan Cox wrote:
my question is:
what kind of problem can have this serveur:
hardware or software ?
What sort of watchdog are you using ?
software. no hardware solution.
http://www.ibiblio.org/pub/Linux/system/daemons/watchdog/watchdog-5.1.tar.gz
The software
On Fri, Dec 01, 2000 at 01:30:10PM -0500, Phillip Ezolt wrote:
Any ideas? (Or patches that I can test... ;-) )
miata seems to use cia southbridge so it should set an iommu direct mapping
large 2G. So it's maybe the second window between 1G and 2G that isn't set
correctly? Does the qlogic
On Wed, Nov 29, 2000 at 03:01:59PM -0700, Tom Rini wrote:
As Dave Miller pointed out, DEV_MAC_HID sysctl conflicts with the RAID patches
That's right but OTOH I'd simply declare the sysctl-by-number interface dead
for new introduced sysctl. We need to preserve backwards compatibility of
course
On Friday December 1, [EMAIL PROTECTED] wrote:
Please CC to me because I'm not a LKML subscriber.
Hi,
I found a real showstopper problem in the SoftwareRAID autodetect
code; 2.4.0-test10 and 2.4.0-test11 are affected (I didn't test
previous versions).
Fixed in 2.4.0-test12pre3.
If you
Andrea,
large 2G. So it's maybe the second window between 1G and 2G that isn't set
correctly?
What data structure's would I look at? What should I investigate to
verify this?
Does the qlogic driver works on a tsunami southbridge?
What would I have to do to test this? I have an
On Fri, Dec 01, 2000 at 09:26:29AM +, David Woodhouse wrote:
[EMAIL PROTECTED] said:
Not necessarily - it all depends on what your driver does. In many
cases, supporting 2.2 and 2.4 is easy, and all you need are a few
#if's. It's certainly much better to have a dozen or so #if's
Hi.
I recently investigated an 'unused function' warning in iph5526.c. Looking
at it (both the code causing the warning and the whole driver) convinced
me that the driver cannot be used without PCI enabled.
I therefore propose that we add a dependency in net/Config.in for this
driver and clean
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote:
What data structure's would I look at? What should I investigate to
verify this?
The relevant code is in arch/alpha/kernel/core_cia.c
What would I have to do to test this? I have an ES40 3 miata's
Does the qlogic
[Marc Mutz]
+TOPDIR := $(shell pwd -P)
That is specific to the bash builtin 'pwd'. GNU sh-util's pwd does
not know that option (at least not my version, which is: "pwd (GNU
sh-utils) 1.16")
It passed my 5-second shell feature portability test (ash). Checking
again, I see that the ash
I don't have really good numbers for either, but I can say that I was
really impressed with this firewall yesterday. there were other problems
in the system that caused things to clog up, but a 2.4 AMD950 PC133 ram
system was useable (slow, but useable) with 4000+ processes and a loadave
of 300
Hello,
On Fri, 1 Dec 2000, Ben McCann wrote:
I'm curious about how ICMP redirect is causing this problem.
Would you elaborate on how ICMP is involved?
The masq box sends ICMP redirects to the internal host
when the destination host is on the same shared media, i.e.
"please,
Hi!
It's great that you could fix that!
Is there any chance that we will see this patch as well as your other
Alpha patches included in future 2.2.X and 2.4.X releases?
Thanks,
Reto
Andrea Arcangeli wrote:
There were a few SMP races that could trigger only using threads:
1)
On Fri, 1 Dec 2000 17:51:09 +0800, Andrey Savochkin [EMAIL PROTECTED] wrote:
I've been promised that this issue would be looked up in Intel's errata by
people who had the access to it, but I haven't got the results yet.
There is nothing relevant in the errata, unfortunately...
The card
On Fri, Dec 01, 2000 at 08:28:57AM -0800, Reto Baettig wrote:
Is there any chance that we will see this patch as well as your other
Alpha patches included in future 2.2.X and 2.4.X releases?
Yes, for 2.2.x I'm waiting 2.2.19pre, for 2.4.x as DaveM suggested we first
need to cleanup the
Here's the oops. This is an AIC7xxx controller. This is a non-SMP kernel,
and there is only one processor installed in the machine. The value in eax
sure looks weird too me, esp. given that the failing instruction involves
a ld from (%eax)
This is a va2200 node, and this same kernel has booted
On Fri, Dec 01, 2000 at 02:56:43PM -0500, Phillip Ezolt wrote:
What data structure's would I look at? What should I investigate to
verify this?
In the arch/alpha/kernel/pci_iommu.c change
#define DEBUG_ALLOC 0
to
#define DEBUG_ALLOC 2
Perhaps this will give us more info.
At the first look
http://resourcemanagement.unixsolutions.hp.com/WaRM/schedpolicy.html
Changes included:
1.a new benchmark for realtime testing called sched_rr
2.a fix to YIELD code in pset.c which could result in a hang after
cpu assign of a busy cpu on Linux 2.2.16.
3.the release of a
[Tracy Camp]
A much cleaner patch prompted after right proper chastisement on the
sloppy patch I sent a few days back. This one is against 2.4-pre11
Hmmm, I don't like your array thing (also in v.I of the patch),
limiting us to n possible root devices, where n==8. A better
approach might be
[I wrote]
Your patch makes it impossible, in this situation, to override the
default root device from the syslinux command line. A kludge to make
it work again would be to process the root devices in reverse.
Better would be to reset the list of root devices with every 'root='
statement,
[Roger Crandell]
When I boot the machine with the multiprocessor kernel and run
iptables, the kernel dumps several pages of hex and the final two
lines of output are:
Killing interrupt handler
scheduling in interrupt
Look through the "several pages of hex" for any number in square +
On Fri, 1 Dec 2000 14:52:11 + (GMT),
John Levon [EMAIL PROTECTED] wrote:
Probably you have modversions enabled (CONFIG_MODVERSION=y). Disable that
and try again, or build as modules. 2.4 fixed this problem in the proper
way, but I don't know what's going to happen about 2.2 ...
I have sent
On Fri, 01 Dec 2000 09:41:58 -0700,
Roger Crandell [EMAIL PROTECTED] wrote:
Killing interrupt handler
scheduling in interrupt
The kernel logs nothing and you must reset the machine to bring it back
linux/Documentation/oops-tracing.txt
linux/Documentation/serial-console.txt
-
To unsubscribe
On Fri, 1 Dec 2000 10:52:35 -0800 (PST),
Al Peat [EMAIL PROTECTED] wrote:
I've followed the thread on "Persistent module
storage" but haven't come across a general explanation
of the changes to the inter-module symbol stuff
between 2.4test10 and test11. Anyone care to comment
on the
Hi
I'm using kernel version 2.2.14. When the mount
syscall or mount command is called, the user given
name of the mount point isn't resolved. These means
that /proc/mounts will have entries with symlinks
while /etc/mtab will have the real directory.
In the case of smbmnt, chdir is called on
"Stephen C. Tweedie" wrote:
Hi,
On Fri, Dec 01, 2000 at 08:35:41AM +1100, Andrew Morton wrote:
I bet this'll catch it:
static __inline__ void list_del(struct list_head *entry)
{
__list_del(entry-prev, entry-next);
+ entry-next = entry-prev = 0;
}
No, because
Hmmm, I don't like your array thing (also in v.I of the patch),
limiting us to n possible root devices, where n==8. A better
approach might be to iterate over the root= arguments when mounting. I
know why you used the array -- easier to code.
I was unsure if it was okay to be using kmalloc
Followup to: [EMAIL PROTECTED]
By author:Paul Jakma [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
On Fri, 1 Dec 2000, Alan Cox wrote:
Intel PXE uses tftp to download boot images and discards IP packets with
the DF bit set; so a tftpd server on 2.4 with the default
Then Intel
[Tracy Camp]
I was unsure if it was okay to be using kmalloc during early stages
of init/main.c so I decided to follow the example allready set and
just use a static array - can anyone advise on being able to do this
dynamically?
Have a static 'char *' somewhere. In the "root=" callback
On Fri, Dec 01, 2000 at 08:04:52PM -0500, Jeff Dike wrote:
boot memory allocator (see mm/bootmem.c). In the arch that I'm most familiar
with (arch/um), that is usable from the beginning of start_kernel. I don't
know about the other arches.
setup_arch does the necessary initialization on
[Jamie Manley]
Yes, modversions was enabled. Should that be affecting the build of
the kernel proper?
The bug you ran into is that MODVERSIONS messes up the
'get_module_symbol' function, which is a sort of "optional dependency"
mechanism used by a few modules such as DRI (in this case: DRI
[Christopher Friesen]
I think you should re-read the GPL. You only have to provide source
to people to whome you have distributed your new binaries, and you
only have to provide that source if you are asked for it.
Oh, and you have to provide the complete text of the GPL as well, and
for
"Stephen C. Tweedie" wrote:
Hi,
On Fri, Dec 01, 2000 at 08:35:41AM +1100, Andrew Morton wrote:
I bet this'll catch it:
static __inline__ void list_del(struct list_head *entry)
{
__list_del(entry-prev, entry-next);
+ entry-next = entry-prev = 0;
}
No, because
Minutes after slashdot ran their article saying that the
Transmeta recall was limited to about 300 Fujitsu computers, I ran
to Fry's and bought a Sony PictureBook PCG-C1VN. Thank heavens for
those extended Christmas hours I thought, while praying that the
statements about the Crusoe
On Fri, Dec 01, 2000 at 09:22:22PM -0600, Peter Samuelson wrote:
[Jamie Manley]
Yes, modversions was enabled. Should that be affecting the build of
the kernel proper?
The bug you ran into is that MODVERSIONS messes up the
'get_module_symbol' function, which is a sort of "optional
Followup to: [EMAIL PROTECTED]
By author:"Adam J. Richter" [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Well, alas, it appears that linux-2.4.0-test12-pre3 freezes hard
while reading the base address registers of the first PCI device
(the "host bridge"). Actually, I think the
On Sat, 2 Dec 2000, Chris Wedgwood wrote:
On Thu, Nov 30, 2000 at 08:24:02AM -0500, Richard B. Johnson wrote:
This is actually a feature. The directory does not get truncated.
Arguably directories could be truncated when objects towards the end
are removed; I believe UFS under
Followup to: [EMAIL PROTECTED]
By author:Tigran Aivazian [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Second attempt -- the first one got lost due to some local mail client
problems...
Hi Linus,
Here is the patch to microcode update driver to support the new P4
CPU.
---
On Sat, 2 Dec 2000, Chris Wedgwood wrote:
On Sat, Dec 02, 2000 at 12:14:34AM -0500, Alexander Viro wrote:
Not really. Anything that modifies directories holds both -i_sem and
-i_zombie, lookups hold -i_sem and emptiness checks (i.e. victim in
rmdir and overwriting rename)
If I buy one of these machines for testing,
will I be able to upgrade the processor's Code
Morphing Software with the new version when it's
ready? I hear the new CMS code will almost
double the battery life.
Thanks,
Miles
-
To unsubscribe from this list: send the line "unsubscribe
In article 90a065$5ai$[EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED] wrote:
Anyway, I do have this machine working now, although not everything is
to my liking. Unlike older picture-books, for example, this one has a
WinModem. Ugh. And the sound chip is supported, but only by the ALSA
Jens Axboe wrote:
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
Believe it or not, but this is intentional. In that regard, the
function name is a misnomer -- call it i/o scheduler instead :-)
I never believe it intentional. If it is true, the current kernel
will be suffered from
On Friday December 1, [EMAIL PROTECTED] wrote:
On Fri, Dec 01, 2000 at 01:11:45PM +1100, Neil Brown wrote:
On Thursday November 30, [EMAIL PROTECTED] wrote:
Hello people,
I have some trouble with the raid-stuff.
...
Is it just "very slow", but it eventually finishes, it is it so
On Sat, Dec 02, 2000 at 06:56:43AM +1100, Neil Brown wrote:
On Friday December 1, [EMAIL PROTECTED] wrote:
It's so slow that it's unusable. Especially writing. open() and
close()-calls often hang for 20 seconds or more.
write-calls hang for 3-4 seconds. This has to be a bug.
But yes,
Date:Fri, 1 Dec 2000 15:18:42 +0100
From: Andrea Arcangeli [EMAIL PROTECTED]
I'm still left the #ifdef __alpha__ around the context[NR_CPUS] to
avoid breakage of other archs but that should be probably removed:
any CPU with per-CPU ASNs like alpha needs per-CPU per-MM
Hello,
On Thu, Nov 30, 2000 at 07:41:11PM +0100, Udo A. Steinberg wrote:
I've been using an older EEPro100/B card until now and it's been working without any
problems ever since the transmitter bugs were fixed. The boot output looked like
this:
[snip]
Today I've installed a new model with
201 - 254 of 254 matches
Mail list logo
