>> sigp. To synchronize n CPUs one can create n kernel threads and give
>> them a high priority to make sure they will be executed soon (e.g. by
>> setting p->policy to SCHED_RR and p->rt_priority to a very high
>> value). As soon as all CPUs are in synchronized state (with
>> interrupts
Hello,
On Mon, Dec 11, 2000 at 10:52:19AM -0800, Tom Murphy wrote:
>Also, regarding the eepro100 driver, are there any plans to fix
> support for the following chipset (given by lspci):
>
[snip]
> I have one of these at work and I will get the following messages:
>
> Dec 11 10:46:13
Hello,
It appears that Linus has picked up most (if not all) of the patches with the
release of 2.4.0-test12-final. I'm building 2.4.0-test12 now.
Regards,
-Frank
--Original Message--
From: "Mohammad A. Haque" <[EMAIL PROTECTED]>
To: linux-kernel <[EMAIL PROTECTED]>
Sent: December 12,
Al Peat writes:
> Quick question about blocks:
>
> If I assume my hard drive uses 512 blocks, and my
> ext2 filesystem uses 4k blocks, can I assume the
> following formula for translation?
>
> physical block # / 8 = e2fs block #
It really depends on what you are calculating. Ext2 uses
[AC]
> > ... added basic support for the Pentium IV.
[Android]
> How is the Pentium IV more advanced than the Pentium III, other than
> speed? Why would LInux care about a 1500 MHz clock or 400 MHz bus
> speed? Just treat the PIV as a faster PIII.
It all sounds so simple, right?
> ... added basic support for the Pentium IV. Unfortunately Intel
chose to
> ignore all precedent in model numbering via cpuid and report a
> family of '15'. This sudden jump broke assumptions in the
> kernel tree without any warning. Intel have failed to
On Mon, 11 Dec 2000, Steven Cole wrote:
> On Mon, 11 Dec 2000, Mike Galbraith wrote:
> > On Mon, 11 Dec 2000, Steven Cole wrote:
> > > I have a SMP (dual P-III 733Mhz) machine at work, but it will be
> > > unavailable for testing for a few more days. I suspect that 2.4.0-test12
> > > will do
On Mon, 11 Dec 2000, Mike Galbraith wrote:
> On Mon, 11 Dec 2000, Steven Cole wrote:
> > I have a SMP (dual P-III 733Mhz) machine at work, but it will be
> > unavailable for testing for a few more days. I suspect that 2.4.0-test12
> > will do better than 2.2.18 with 2 CPUs. I'll know in a few
- test12pre8, i586, 128MB, narrow aha2940 (aic7xxx, no tag queueing)
- LVM (0.8final) and MD RAID5 compiled in
I was experimenting with LVM over MD (I thought this was supposed to
work but had never tried it).
# mkraid /dev/md0 (ok)
# pvcreate /dev/md0 (ok)
#
On Mon, 11 Dec 2000, Steven Cole wrote:
> I have a SMP (dual P-III 733Mhz) machine at work, but it will be
> unavailable for testing for a few more days. I suspect that 2.4.0-test12
> will do better than 2.2.18 with 2 CPUs. I'll know in a few days.
>
> Building kernels is something we do so
http://oss.sgi.com/projects/kdb/download/ix86/ contains patches for kdb
v1.7 against 2.4.0-test11 and 2.4.0-test12.
There is a large amount of internal reorganisation from kdb v1.6 to
v1.7 to make it easier to support multiple architectures. Most of this
is feedback from the kdb for IA64 work
During the writing of a CDRW, I had a pair of oopses. System uptime was
48 days, CD writing has never failed before. Below are the OOPSes after
being passed through ksymoops 2.3.5 . If anything interesting comes of
this, I'd be interested in hearing it, so could you cc me any replies?
The
[Al Peat]
> Quick question about blocks:
>
> If I assume my hard drive uses 512 blocks, and my
> ext2 filesystem uses 4k blocks, can I assume the
> following formula for translation?
>
> physical block # / 8 = e2fs block #
Not if you have a partition table. If you take into account the
[Georg Nikodym]
> + case 'x':
> + fprintf(stderr,
> + "klogd: %c option is obsolete. Ignoring\n", ch);
Clearer (IMHO): "klogd: warning: ignoring obsolete option '-%c'\n", ch);
Peter
-
To unsubscribe from this list: send
[Paul Fulghum]
> from my scanning of the kernel archives, this is the *all time*
> largest kernel patch (including 2.3/2.4 patches).
And thus it follows that 2.2.18 is the least buggy kernel ever, since
it has gotten the most bug fixes.
Right? (:
Peter
-
To unsubscribe from this list: send
From: "Alan Cox" <[EMAIL PROTECTED]>
> Linux 2.2.18 Release Notes
patch-2.2.18.tar.gz size=2.9MBytes
from my scanning of the kernel archives, this is the *all time*
largest kernel patch (including 2.3/2.4 patches).
Go team :-)
Paul Fulghum
-
To unsubscribe from this list: send the line
Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list
compile fixes and (b) the NetApp snapshot thing.
Dave's merge_segments thing could in theory be a deadlock on SMP.
Linus
- final:
- David Miller: sparc and net updates. Fix merge_segments.
> "Dave" == davej <[EMAIL PROTECTED]> writes:
Dave> On Mon, 11 Dec 2000, Jamie Lokier wrote:
>> Here are a few more:
>>
>> net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,
Dave> Acenic is at least setting it to the correct values, not
Dave> hardcoding it.
Nod, it's
> "Dave" == davej <[EMAIL PROTECTED]> writes:
Dave> Hi, I noticed a lot of drivers are setting the
Dave> PCI_CACHE_LINE_SIZE themselves, some to
Dave> L1_CACHE_BYTES/sizeof(u32), others to arbitrary values (4, 8,
Dave> 16).
Dave> Then I spotted that we have a routine in the PCI subsystem
> Daryll> On Sat, Dec 09, 2000 at 09:34:59PM -0500, David Feuer wrote:
> >> For what it's worth, I absolutely agree with this. I have the same
> >> impression when I just see the word "dangerous".
>
> Daryll> Why not call a spade a spade and label it BROKEN. I do think
> Daryll> that's stronger
On Sun, 10 Dec 2000, Alan Cox wrote:
> > Is it "obvious" that I'm dealing with the same or similar kind of
> > bugginess here?
>
> Obvious no, but its a pretty good guess.
FWIW, I now get:
-
neale@gull:~$ cat /proc/apm
1.13 1.1 0x03 0xff 0xff 0xff -1% -1 ?
> "Daryll" == Daryll Strauss <[EMAIL PROTECTED]> writes:
Daryll> On Sat, Dec 09, 2000 at 09:34:59PM -0500, David Feuer wrote:
>> For what it's worth, I absolutely agree with this. I have the same
>> impression when I just see the word "dangerous".
Daryll> Why not call a spade a spade and
Linux 2.2.18 Release Notes
Platforms:Alpha, M68K, PowerPC, S/390, Sparc, X86
Introduction
Linux 2.2.18 is the latest update to the Linux kernel tree. The out of
the box tree supports the Alpha, PPC, Sparc and X86 platforms. MIPS
and ARM are mostly merged but you should
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> Looks good, except that you need to keep the option flags for
KO> backwards compatibility. There are a *lot* of scripts out there
KO> which invoke klogd with various options and they will fail with
KO> this change. It is OK to issue
[Mohammad A. Haque]
> Wasn't there discussion that user space apps shouldn't include kernel
> headers?
Oh, it's been discussed, many times. Here is my executive summary of
why nobody needs to use kernel headers in userspace programs, *EVER*:
Q: I want to #include but I get compile errors,
>The problem seems to be the "pci_get_interrupt_pin()" call. We should not
>do that. The pirq table has the unmodified device information - and when
>we try to swizzle the pins and find the bridge that the device is behind,
>we're trying to be way too clever.
Both with/without the change you
On Mon, 11 Dec 2000 20:13:46 -0500 (EST),
"Georg Nikodym" <[EMAIL PROTECTED]> wrote:
>Here's a patch (against sysklogd-1.3-31) that completely tear out the
>symbol processing code.
Looks good, except that you need to keep the option flags for backwards
compatibility. There are a *lot* of
> "GN" == Georg Nikodym <[EMAIL PROTECTED]> writes:
GN> Here's a patch (against sysklogd-1.3-31) that completely tear out
GN> the symbol processing code.
Doh! Forgot a chunk (to be applied after the others):
diff -Nru a/src/sysklogd-1.3-31/Makefile b/src/sysklogd-1.3-31/Makefile
---
Quick question about blocks:
If I assume my hard drive uses 512 blocks, and my
ext2 filesystem uses 4k blocks, can I assume the
following formula for translation?
physical block # / 8 = e2fs block #
Thanks,
Al
__
Do You Yahoo!?
Yahoo!
Martin,
I finally got access to a machine that truly has multiple PCI buses and
bridges in between them, and at least for that machine the x86 IRQ lookup
does not work at all.
The problem seems to be the "pci_get_interrupt_pin()" call. We should not
do that. The pirq table has the unmodified
} User space applications _must_ not include kernel headers. Even
} modutils does not include linux/module.h, it has its own portable
} (kernels 2.0 - 2.4) version.
There are cases where a user-program _must_ include kernel headers. Some
glibc versions have incorrect values for MCL_* and
On Mon, 11 Dec 2000 21:42:14 -0200,
Fr d ric L . W . Meunier <[EMAIL PROTECTED]> wrote:
>Is this a 2.4.0 issue? Because I see the warnings on 2.2.18
>too, and also building alsa-driver. I use modutils 2.3.22.
>binutils 2.10.1.0.2. glibc 2.2.
The kernel is trying to fudge the section flags for
Wasn't there discussion that user space apps shouldn't include kernel
headers?
"Adam J. Richter" wrote:
>
> linux-2.4.0test12pre8/include/linux/module.h contains some
> kernel-specific declarations that now reference struct list_head, which
> which is only defined when __KERNEL__ is
> "KO" == Keith Owens <[EMAIL PROTECTED]> writes:
KO> klogd maps the kernel messages from text to syslog levels and
KO> does some fiddling with kernel log levels at start up. It needs
KO> to be more than a simple 'cat'. When symbol handling was added
KO> to klogd, ksymoops was built
On Mon, 11 Dec 2000 14:59:01 -0800,
"Adam J. Richter" <[EMAIL PROTECTED]> wrote:
> linux-2.4.0test12pre8/include/linux/module.h contains some
>kernel-specific declarations that now reference struct list_head, which
>which is only defined when __KERNEL__ is set. This causes sysklogd
>and
Frédéric L . W . Meunier wrote:
>
> Alan Cox wrote:
...
There are several typos, but it is not clear if they are all
from ide-pci.c, or in the other files (pci.ids and pci_ids.h).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
this works fine in pre8. thanks all!
Joseph Cheek wrote:
> copying files off a loopback-mounted vfat filesystem exposes this bug.
> test11 worked fine.
>
> loop.o built as module. this hard crashes the machine, every time
> [PIII-450]. i don't know how to debug this, is there a FAQ?
>
>
Alan Cox wrote:
> I disagree with the patch. The bug is in printk
No problem. So, it's a bug report instead. I have no clues,
and just thought it'd be a fix :)
Not sure if 2.2.17 reported the double %% from syslog. I
usually look at my dmesg.
--
0@pervalidus.{net,{dyndns.}org} TelFax:
Hello all
How are we doing on the task queue updates?
--
=
Mohammad A. Haque http://www.haque.net/
[EMAIL PROTECTED]
"Alcohol and calculus don't
[John O'Donnell]
> The directory of kernel headers (version 2.2.17) does not match your
> running kernel (version 2.2.18). Consequently, even if the
> compilation of the module wassuccessful, the module would not load
> into the running kernel.
> Upon inspection of
The character device is a good idea!!!
But how would the device's mmap be implemented?
I know how the read and write work, but they copy the data from one space
to another, which would be slow if there is much communication. Because
this looses the benifits of shared memory
About the kernel
On Thu, 7 Dec 2000, Alan Cox wrote:
> Andreas is looking at a slightly older kernel, and was right for that. Every
> caller to daemonize either then did the file stuff or needed to and forgot
> so I fixed daemonize
I think, there ist still a small bug.
(This time I even checked
On Tue, 12 Dec 2000, Alan Cox wrote:
> No idea on the sensors stuff
i'll go nag them again. :)
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
You will lose an important
On Tue, 12 Dec 2000, Alan Cox wrote:
> > like i said, their code has worked well for me, but they seem intent
> > on keeping it as obscure as possible... (i remember someone posted to
> No idea on the sensors stuff
Whats keeping lm78 from being integrated into 2.4?
-Dan
-
To unsubscribe from
> it is? i don't see the sensors stuff, so you must mean just the i2c
> bits. Any word on whether we'll see sensors code go in to 2.4?
The i2c bits
> like i said, their code has worked well for me, but they seem intent
> on keeping it as obscure as possible... (i remember someone posted to
No
I have downloaded the updated (v1e08 June 09th, 2000) driver from ami,
this appers to work (apart from a tendency to reset the bus).
--
Tim Fletcher - Network manager .~.
/V\ L I N U X
[EMAIL PROTECTED]// \\ >Don't fear the
It's in 2.4? Where?
Alan Cox wrote:
>
> > do these guys /ever/ plan on submitting kernel patches? i used to use
> > lm_sensors on 2.2 cause it was fairly painless - but just havn't
> > bothered with 2.4 cause it was a pita when i tried.
>
> Its in 2.4 it wont be in 2.2 I suspect
--
On Tue, 12 Dec 2000, Alan Cox wrote:
> Its in 2.4 it wont be in 2.2 I suspect
it is? i don't see the sensors stuff, so you must mean just the i2c
bits. Any word on whether we'll see sensors code go in to 2.4?
like i said, their code has worked well for me, but they seem intent
on keeping it as
> In sched.c, function daemonize, line 1216 you call exit_mm.
Yep
> time, it has to segvault. If I am not wrong at this point CLONE_VM simply
> has to be removed from kernel_thread. The kernel-thread will free his mem
> in daemonize (calling exit_mm) and the user-space-application will free
>
[Rasmus Andersen]
> How about this patch? It moves the offending struct to the __init
> function where it is used and inside an existing #ifdef CONFIG_PCI.
H, if you're messing around with the pci device table, why not just
convert it to use new-style PCI init? This is fairly easy to do (I
> if ((dev->class & ~(0xfa)) != ((PCI_CLASS_STORAGE_IDE << 8) | 5)) {
> - printk("%s: not 100%% native mode: will probe irqs later\n", d->name);
> + printk("%s: not 100% native mode: will probe irqs later\n", d->name);
> pciirq =
James Simmons <[EMAIL PROTECTED]> writes:
> Just played with this bug. It doesn't kill a login shell but does any
> app running on it. I just went looking for where "Quit" is printed
> out. When I press SysRq Quit is printed on the command line. Any ideas?
Not a bug. Normally,. PrtSc will
> do these guys /ever/ plan on submitting kernel patches? i used to use
> lm_sensors on 2.2 cause it was fairly painless - but just havn't
> bothered with 2.4 cause it was a pita when i tried.
Its in 2.4 it wont be in 2.2 I suspect
-
To unsubscribe from this list: send the line "unsubscribe
On Mon, Dec 11, 2000 at 01:56:22PM -0500, [EMAIL PROTECTED] wrote:
> Technical merits and voter intent aside, this behavior is misleading and
> inconsistent with previous kernels. Tools like top or a CPU dock applet show
> a constantly loaded CPU. Hacking them to deduct the load from 'kapm-idled'
Is this a 2.4.0 issue? Because I see the warnings on 2.2.18
too, and also building alsa-driver. I use modutils 2.3.22.
binutils 2.10.1.0.2. glibc 2.2.
2.2.17 reported the same, 2.4.0-test11 too (but I never ran
this one).
The compiler is egcs 1.1.2. gcc is a symlink to egcs-2.1.96.
--
Yo All!
Scott McDermott <[EMAIL PROTECTED]> convinced me the way
to fix my problem with SMBFS was to use the INIT_LIST_HEAD() macro.
This allows SMBFS to compile and may even be correct:
--- sock.c.dist Mon Dec 11 15:26:56 2000
+++ sock.c Mon Dec 11 15:27:03 2000
@@ -163,7 +163,7 @@
On Sun, 10 Dec 2000, Mohammad A. Haque wrote:
> Hit http://www.lm-sensors.nu/
do these guys /ever/ plan on submitting kernel patches? i used to use
lm_sensors on 2.2 cause it was fairly painless - but just havn't
bothered with 2.4 cause it was a pita when i tried.
i know they talked AC at some
Thanks for your advice,
I already know one way to accomodate shared memory between a user process
and the kernel.
This is done by making a character device which allocates memory in the
kernel, then from the user appl, using the mmap function of the driver.
I was only wondering why I could not
(This message contains a number of related replies.)
> From: Mike Galbraith [mailto:[EMAIL PROTECTED]]
> Is init permanently running after you see a couple of these?
No, that is, after 23 hours up time it has used only 6 seconds CPU time
(according to top).
That reminds me that I should repeat
It's been a few months (and a couple of kernel releases) since I mentioned this
before and it doesn't look like it's made it in, and I haven't seen any more
comments on it in the list archives, so I'm bringing it up again in case it
just got forgotten about somewhere along the line..
As I
dmesg: VP_IDE: not 100% native mode: will probe irqs later
syslog: Dec 11 14:28:48 pervalidus kernel: VP_IDE: not 100%% native mode: will probe
irqs later
--
0@pervalidus.{net,{dyndns.}org} TelFax: 55-21-717-2399 (Niterói-RJ BR)
--- linux/drivers/block/ide-pci.c.old Sun Dec 10 23:10:22
Date: Mon, 11 Dec 2000 23:07:01 +0100 (CET)
From: Gérard Roudier <[EMAIL PROTECTED]>
So, if you want to fix this insane PCI interface:
1) Provide the _actual_ BARs values in the pci dev structure, otherwise
drivers that need them will have to deal with ugly hackery or access
Hello!
> It is the bar cookies in pci dev structure that are insane, in my opinion.
>
> If a driver needs BARs values, it needs actual BARs values and not some
> stinking cookies. What a driver can do with BAR cookies other than using
> them as band-aid for dubiously designed kernel interface.
"Mohammad A. Haque" wrote:
>
> Thinko.
>
> Question is... Adam Richter posted a patch for i2o_lan.c that does
> this...
>
> static struct tq_struct i2o_post_buckets_task = {
> list: LIST_HEAD_INIT(i2o_post_buckets_task.list),
> sync: 0,
> routine: (void (*)(void
>--- atyfb.cMon Dec 11 14:28:19 2000
>+++ atyfb.c.orig Wed Oct 4 22:22:28 2000
>@@ -2796,7 +2796,7 @@
> * works on iMacs as well as the G3 powerbooks. - paulus
> */
> if (default_vmode == VMODE_CHOOSE) {
>- if ((Gx == LG_CHIP_ID)||(Gx == LI_CHIP_ID)||(Gx ==
On Mon, 11 Dec 2000, David S. Miller wrote:
>Date: Mon, 11 Dec 2000 22:30:59 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
>
>On Mon, 11 Dec 2000, David S. Miller wrote:
>
>> Really, in 2.4.x sparc64 requires PCI config space hackery no longer.
>
>Really?
>
>
Aaron Tiensivu wrote:
>Rerun the 2.4.0 with kgcc to be fair. :)
John Fremlin wrote:
>Two points: (1) gcc 2.95 makes slightly slower code than egcs-1.1
>(according to benchmarks on gcc.gnu.org) so compile 2.4 kernel with
>egcs for a fairer comparison. (2) The new VM was a performance
Ok, several
> Hi!
>
> > I don't remember having the same problem months (6?) ago when
> > I built my first Kernel with this enabled (well, maybe I never
> > touched the key).
> >
> > When built into the Kernel, by only pressing the
> > PrintScreen/SysRq the current application is terminated (tested
> > on
linux-2.4.0test12pre8/include/linux/module.h contains some
kernel-specific declarations that now reference struct list_head, which
which is only defined when __KERNEL__ is set. This causes sysklogd
and probably any other user level program that needs to include
to fail to compile.
Here's an update for my patch to enable the just released 2.2.18 kernel
to compile with any of the different versions of the StackGuard
compiler.
If anyone has any problems with it, please let me know,
greg k-h
--
greg@(kroah|wirex).com
http://immunix.org/~greg
diff -Naur -X
Ben Ford wrote:
> Why would you *ever* want to write a device driver in perl???
Well, Perl, I don't know. But the USB 'driver' for my Canon PowerShot
S20 runs in userspace. Seems a safer place to do things.
-M
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
The previous patch for 2.2.X for 2.4.0-testX.
--- atyfb.c.origMon Dec 11 14:38:11 2000
+++ atyfb.c Mon Dec 11 14:35:03 2000
@@ -3621,7 +3621,7 @@
}
#endif
if (default_vmode == VMODE_CHOOSE) {
- if (Gx == LG_CHIP_ID || Gx ==
As Keith Owens pointed out klogd mangled the decode, I haev run it through
ksymoops and got the following decode:
ksymoops 2.3.4 on i686 2.4.0-test11. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test11/ (default)
Date: Mon, 11 Dec 2000 22:30:59 +0100 (CET)
From: Gérard Roudier <[EMAIL PROTECTED]>
On Mon, 11 Dec 2000, David S. Miller wrote:
> Really, in 2.4.x sparc64 requires PCI config space hackery no longer.
Really?
I was thinking about the pcivtophys() alias bus_dvma_to_mem()
Yo All!
I just tried to compile SMBFS in test12-pre8. Here is the error
message I get:
make[3]: Entering directory `/u3/local/src/linux-2.4.0-test12-pre8/fs/smbfs'
gcc -D__KERNEL__ -I/usr/local/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -fno-strict-aliasing -pipe
> How much of that is due to the fact that the 2.4.0 scheduler interrupts
> processes more often than 2.2.x? Is the better interactivity worth the
> slight drop in performance?
What better interactivity ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
This patch allows you select different modes on a Mac. The functionality
was there but not taken advantage of. This is needed because the resolution
can be 834x628 on a Mac and the screen is really screwed up with more than
8 bit in that case.
--- fbmem.c.origMon Dec 11 14:18:44 2000
On Mon, 11 Dec 2000, David S. Miller wrote:
>Date: Mon, 11 Dec 2000 21:49:52 +0100 (CET)
>From: Gérard Roudier <[EMAIL PROTECTED]>
>
>If now, the PCI stuff is claimed to be cleaned up, then _all_ the
>hacks have to be removed definitely. As a result, the driver will
>
Date: Fri, 8 Dec 2000 16:58:55 +0100
From: Andi Kleen <[EMAIL PROTECTED]>
On Fri, Dec 08, 2000 at 07:28:15AM -0800, David S. Miller wrote:
> I agree, I'll kill it unless you want to commit to this work
> Andi. :-)
Kill it ;)
Done.
Seriously, if someone wants to do this work
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Mon, Dec 11, 2000 at 04:38:11PM -0200, Rik van Riel wrote:
> On 11 Dec 2000, John Fremlin wrote:
>
> > Two points: [snipped]
>
>
> Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> for the VM doesn't make any sense since it doesn't really excercise
> the VM
Hi all,
sorry, next time I should at least do sanity checks on my own email.
Of course 5.2.1 as in latest-test is newer than 5.1.something.
Just did a quick look in the source and on Dougs site and mixed the version
numbers up. Stupid me!
Greetings,
Michael Meding
-
To unsubscribe from this
Date:Mon, 11 Dec 2000 21:49:52 +0100 (CET)
From: Gérard Roudier <[EMAIL PROTECTED]>
If now, the PCI stuff is claimed to be cleaned up, then _all_ the
hacks have to be removed definitely. As a result, the driver will
not work anymore on Sparc64, neither on PPC and I am not
On Mon, 11 Dec 2000, Alan Cox wrote:
> > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> > for the VM doesn't make any sense since it doesn't really excercise
> > the VM in any way...
>
> Its an interesting demo that 2.4 has some performance problems since 2.2
> is slower
On Mon, 11 Dec 2000, Martin Mares wrote:
> Hello Gerard!
>
> > Having to call some pdev_enable_device() to have the cache line size
> > configured looks like shit to me. After all, the BARs, INT, LATENCY TIMER,
> > etc.. are configured prior to entering driver probe.
>
> Once upon a time,
Hi all,
am I right that the aic7xx version in latest test is 5.2.1 ? Is there a
reason why this is not up to date to Doug Ledfords 5.1.31 ?
TIA
With best regards
Michael Meding
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi!
> > This email is here to announce the availability of a port of ORBit (the
> > GNOME ORB) to the Linux kernel. This ORB, named kORBit, is available from
> > our sourceforge web site (http://korbit.sourceforge.net/). A kernel ORB
> > allows you to write kernel extensions in CORBA and have
Hi!
> I don't remember having the same problem months (6?) ago when
> I built my first Kernel with this enabled (well, maybe I never
> touched the key).
>
> When built into the Kernel, by only pressing the
> PrintScreen/SysRq the current application is terminated (tested
> on a console and GNU
Hi!
> Bought myself this new CPU that is mainly available for laptops.
>
> I have Tyan S1590 board which BIOS won't POST if I set cpu speed (it's
> 500Mhz chip) >300Mhz. This won't matter much in windows since I can there
> use graphical utility which allows one to set whe CPU clock multiplier
> > - I don't think we can say that the kernel hotplug interface is
> > complete until we have real, working, tested userspace tools. David,
> > could you please summarise the state of play here? In particular,
> > what still needs to be done?
>
> Well, for USB I would like to know
On Sat, Dec 09, 2000 at 12:41:24AM -0500, Theodore Y. Ts'o wrote:
>
> There was is usual with these sorts of things, multiple problems I was
> dealing with. The first was that I was trying to use cardmgr, and my
> pcmcia config file was still trying to load epic_cb. Oops. David, you
> might
Hi Linus!
> My tentative fix for this would be to make Linux never assign bus #1 or #2
> to a cardbus bridge, and start cardbus bridges at bus #8 or something like
> that. That way we'd still catch any strangeness in the pirq table, but we
> wouldn't get the message for this case which seems to
Hello Gerard!
> Having to call some pdev_enable_device() to have the cache line size
> configured looks like shit to me. After all, the BARs, INT, LATENCY TIMER,
> etc.. are configured prior to entering driver probe.
Once upon a time, they used to be, but they no longer are. Unfortunately,
On Mon, 11 Dec 2000 [EMAIL PROTECTED] wrote:
> On Mon, 11 Dec 2000, Jamie Lokier wrote:
>
> > Here are a few more:
> >
> > net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,
>
> Acenic is at least setting it to the correct values, not hardcoding it.
>
> > net/gmac.c:
On Mon, 11 Dec 2000 15:03:47 [EMAIL PROTECTED] wrote:
>
> Recently I had some thoughts on how to realise CPU attachment and
> detachment in a running Linux system (based on the 2.4 kernel).
>
> CPU attachment and detachment would make sense on an S/390 when there
> are several Linuxes running,
On Mon, 11 Dec 2000, Matthew Galgoci wrote:
>
> I do however still recieve a nasty message about a pirq table
> conflict, but it does not seem to affect the operation of the
> card.
It doesn't.
> The pirq conflict message seems a little harsh though, and perhaps
> unnecessary.
It is a bit
On Mon, 11 Dec 2000, Alan Cox wrote:
> > Doing a 'make bzImage' is NOT VM-intensive. Using this as a test
> > for the VM doesn't make any sense since it doesn't really excercise
> > the VM in any way...
>
> Its an interesting demo that 2.4 has some performance problems
> since 2.2 is slower
I have a PC164 Alpha (500Mhz) and I get hard lock ups randomly when
accessing the internet. It happens very frequently (like within a few
minutes) with 2.4 kernels, but happens much more infrequently with 2.2
kernels. Also, I have to compile the kernel for generic alpha (NOT PC164)
On Mon, 11 Dec 2000, Dietmar Kling wrote:
> > You do realize what "evolution" means? I'm not talking about the bugs
> > in implementation. I'm talking about botched design. _That_ never gets
> > fixed. Show me one example when that would happen and I might consider
> > taking such possibility
On Mon, 11 Dec 2000, Jamie Lokier wrote:
> Here are a few more:
>
> net/acenic.c: pci_write_config_byte(ap->pdev, PCI_CACHE_LINE_SIZE,
> net/gmac.c: PCI_CACHE_LINE_SIZE, 8);
> scsi/sym53c8xx.c: printk(NAME53C8XX ": PCI_CACHE_LINE_SIZE set to %d (fix-up).\n",
For this one, this happens on
1 - 100 of 329 matches
Mail list logo
