dean gaudet writes:
> also, for order > 7, was the real intention to use a shift of
> (order*2)&31?
No, the whole thing is buggered. How stupid, my fault.
It was the 64-bit platform fascist at work :-)
How does this work for you (against 2.4.x)?
--- fs/dcache.c.~1~ Tue Feb 6 23:00:58
> much-improved block layer of 2.4.x throws larger I/Os at the driver. So,
> the developers at Adaptec are busy trying to add support to break large
> requests into smaller chunks, and then gather them back together.
That sounds like it should be doable at the queuing layer. If not the scsi
On Thu, Feb 08, 2001 at 03:35:00AM +0100, Udo A. Steinberg wrote:
>
> I'm not sure whether this is related to the ominous ps/2 mouse bug
> you have been chasing, but this problem is 100% reproducible and
> very annoying.
>
> After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer
>
> I'm not sure whether this is related to the ominous ps/2 mouse bug
> you have been chasing, but this problem is 100% reproducible and
> very annoying.
It isnt but it might be related to which 2.2.19pre you are running (if any)
> After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no
On Thu, 8 Feb 2001, Alan Cox wrote:
> > It's the printk that gets it wrong, although that's harmless.
> > Intel's documentation states that the bug does NOT exist if the
> > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> > the printk is wrong.
>
> So why does it fix the
> It's the printk that gets it wrong, although that's harmless.
> Intel's documentation states that the bug does NOT exist if the
> bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> the printk is wrong.
So why does it fix the problem for him. His report and your reply don't
On Wed, Feb 07, 2001 at 11:23:01PM -0800, Ion Badulescu wrote:
> Intel's documentation states that the bug does NOT exist if the
> bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> the printk is wrong.
I wonder if it's not Intel's documentation which is wrong : it seems
that
This is relative to the 5.2.2 driver already in 2.4.1-ac4 and it fixes the
7880 (and similar) problems. Alan, you'll need to make sure the little patch
I sent earlier is not already applied to your tree since it will conflict with
this patch.
This has been tested on a 7850, 7880, 7890, and
On Thu, 8 Feb 2001 14:53:55 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
> --- linux-2.4.1/drivers/net/eepro100.c Sun Jan 28 03:40:14 2001
> +++ linux-2.4.1-vido1/drivers/net/eepro100.cThu Feb 8 14:08:49 2001
> @@ -815,7 +815,7 @@
>
> sp->phy[0] = eeprom[6];
>
this looks to be a problem going back all the way to at least 2.2.
if you've got 512Mb of RAM you end up with a dentry cache of order 7 --
65536 entries.
this results in a D_HASHBITS of 16. if you look at d_hash it contains
this code:
hash = hash ^ (hash >> D_HASHBITS) ^ (hash >>
I'm getting hundreds of thousands of "DMA overrun on send" messages
in my kernel logs from the i810_audio driver. Help! I'm running stock
Linux 2.4.1.
-- syslog --
Feb 7 22:34:27 angeline kernel: Intel 810 + AC97 Audio, version 0.01, 22:21:54
Feb 7 2001
Feb 7 22:34:27 angeline kernel: PCI:
On 07 Feb 2001 11:48:16 -0500, Chris Mason wrote:
>
>
> On Wednesday, February 07, 2001 08:38:54 AM -0800 David Rees
> <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote:
> >>
> >> Ok, how about we list the known bugs:
> >>
> >> zeros in log files,
Kernel 2.4.1
I have sound support, OSS and my soundcard (sb) configured as modules
If I just play a sound on /dev/dsp, I get the following after the program
exits:
mixcoac:~> cat /proc/modules
sb 2000 0 (autoclean)
sb_lib 33504 0 (autoclean) [sb]
Patch for drivers/net/eepro100.c in kernel 2.4.1 (and before).
For some of the bugged Intel EtherExpress Pro 100 network cards,
although the driver diagnoses the receiver lock-up bug, the workaround
is not enabled. It appears that the test for the diagnostic and the test
for the workaround
Alan,
Attached is a patch against 2.4.1-ac5 which syncs the codec id list and
codec-specific init functions with the ones in my CVS tree. Most of
this is a merge from ALSA, and I would put the changes in the category
"needs to go to Linus, but only after a bunch of testing"
Important changes:
Mikael Pettersson wrote:
>
> H. Peter Anvin wrote:
>
> >"Maciej W. Rozycki" wrote:
> >...
> >> It might be viable just to delete the test altogether, though and just
> >> trap #GP(0) on the MSR access. For the sake of simplicity. If a problem
> >> with a system ever arizes, we may handle it
Petr Vandrovec wrote:
> It is known bug which I reported to Andre already. Open
> drivers/ide/ide.c in favorite text editor, and replace strange
> body of ide_delay_50ms() with simple mdelay(50). Promise driver
> invokes ide_delay_50ms with interrupts disabled, so it freezes
> here forever. If
The same here. I have had no problems with either 2.4.0 or 2.4.1,
and I don't even have the Axboe's patch applied. Which makes me
wonder where is the problem.
I am also using encryption (patch-int-2.4.0.3, idea cipher) and
util-linux-2.10o. The container file is not as big, only 256MB
with
H. Peter Anvin wrote:
>"Maciej W. Rozycki" wrote:
>...
>> It might be viable just to delete the test altogether, though and just
>> trap #GP(0) on the MSR access. For the sake of simplicity. If a problem
>> with a system ever arizes, we may handle it then.
>>
>> Note that we still have to
Hi Alan,
As promised, here is the same driver ported to 2.2.x. I used the
definitions in kcomp.h, as well as the excellent stuff from emu10k1's
wrapper.
The patch was generated agains 2.2.18, but I checked that it applies
cleanly to 2.2.19pre8.
BTW, would you consider a patch adding more
Problem solved. I downloaded the latest reiserfs_utils 3.6.25 from
namesys.com and built and ran reiserfsck against the partition with the
--rebuild-tree option. It completed successfully and I was able to mount
the partition without any further problems.
I'll build and install a 2.4.1 kernel
Manfred Spraul wrote:
>
> Jeff Garzik wrote:
> >
> > + SET_MODULE_OWNER(dev);
> >
> > irq = pdev->irq;
> >
>
> One question:
> The code copies 'pdev->irq' into 'dev->irq'.
>
> Is that required, who need 'dev->irq'?
>
> > retval = request_irq(dev->irq, _handler, SA_SHIRQ,
Dan Kegel <[EMAIL PROTECTED]> wrote:
>
>Tony, are people using the TCP_NOPUSH define as a way to detect
>the presence of T/TCP support?
No, MSG_EOF is the right way to do that.
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]
FAIR ISLE: WESTERLY VEERING NORTHERLY 4 OR 5. WINTRY
[EMAIL PROTECTED] wrote:
> diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/defxx.c
>linux-dj/drivers/net/defxx.c
> --- linux/drivers/net/defxx.c Wed Feb 7 21:55:56 2001
> +++ linux-dj/drivers/net/defxx.cWed Feb 7 22:34:27 2001
applied
> diff -urN
2.4.2-pre1 + ReiserFS 3.6.25 (included) + loop-4
ksymoops 2.3.7 on i686 2.4.2-pre1. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.2-pre1/ (default)
-m /boot/System.map (specified)
Unable to handle kernel NULL pointer
On Wed, Feb 07 2001, [EMAIL PROTECTED] wrote:
> > I haven't seen this driver, but if it uses the SCSI layer instead
> > of being a "pure" block driver then I can see a slight problem
> > in that currently only understand max sg entry limits and not
> > total request sizes. I would rather fix this
Linux Kernel,
The PCI-SCI Drivers for the Dolphin Scalable Coherent Interface
v1.2-1 has posted at vger.timpanogas.org:/sci/pci-sci-1.2-1. This
release corrects several hardware related bugs, and corrects
several previously reported build and performance problems related
to the RedHat 7.1
> I haven't seen this driver, but if it uses the SCSI layer instead
> of being a "pure" block driver then I can see a slight problem
> in that currently only understand max sg entry limits and not
> total request sizes. I would rather fix this limitation then, and
> would also be interested to
On Wed, Feb 07 2001, [EMAIL PROTECTED] wrote:
> Adaptec is still working on it. Basically (and as Jason discovered), the
> driver and firmware can't handle single I/O requests larger than 64KB. Even
> when scatter/gathered, if the total is >64KB, it chokes. This was just fine
> for 2.2.x (no
AH HA! Thanks!
- Original Message -
From: "David Woodhouse" <[EMAIL PROTECTED]>
To: "Jim Roland" <[EMAIL PROTECTED]>
Cc: "J. Dow" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 2:37 AM
Subject: Re: RedHat kernel RPM 2.2.16
>
> [EMAIL PROTECTED] said:
> >
> I see in the archives of this mailing list that someone was
> working on the
> aacraid driver for the 2.4 kernel however that post was
> almost 2 months old.
Adaptec is still working on it. Basically (and as Jason discovered), the
driver and firmware can't handle single I/O requests larger
Quoting Andre Hedrick <[EMAIL PROTECTED]>:
>
> Dream on if you think "Writeback cacheing is disabled" on all systems
> bye
> default. If you did not wack it. It is not off.
>
Yeah, I know, Andre. I turned it off in the 3ware card's BIOS setup.
I'm not completely idiotic, just dumb enough to
On Wed, 7 Feb 2001, Alan Cox wrote:
> > am not sure how to eliminate or confirm this. Recently I added some RAM
> > (256->384) and decided to get rid of swap. This seemed to have destabilized
> > the system, although nothing is obvious. I can try to stress the system by
>
> Get a copy of
FYI following hints from the linux-crypto mailing-list archives, I am
using the following configuration :
linux-2.4.0
patch-int-2.4.0.3
http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-1.gz
http://www.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.0/loop-bdev-inc-1.gz
"Udo A. Steinberg" wrote:
>
> I'm not sure whether this is related to the ominous ps/2 mouse bug
> you have been chasing, but this problem is 100% reproducible and
> very annoying.
>
> After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer
> receives any mouse events and the mouse
Dream on if you think "Writeback cacheing is disabled" on all systems bye
default. If you did not wack it. It is not off.
On Wed, 7 Feb 2001, Jeff McWilliams wrote:
> Chris,
>
> Thanks for the reply.
>
> > Which reiserfs version is this? Upgrading to the reiserfs included in
> > 2.4.1
Chris,
Thanks for the reply.
> Which reiserfs version is this? Upgrading to the reiserfs included in
> 2.4.1 would be a good plan, there have been a few bug fixes since test9
> times (none specfically related to this).
>
/var/log/messages shows ReiserFS reporting version 3.6.18.
> If this
"A.Sajjad Zaidi" wrote:
> > do you understand that you can't really have raid on ide involving
> > two drives on the same channel?
>
> Is that just because of performance or are there other problems? Its working
> fine as it is, but Im considering setting up all drives as masters (2x
> ATA-100,
Mark Hahn wrote:
> > drives (all IBM-DTLA307045 s) that I realised that the cylinder/head
> > translation is different and I cant use the whole drive unless its
> > partitioned while attached to the other IDE ports.
>
> no, it's just that the bios doesn't perform the LBA geometry lie
> outside
Hi Jeff,
On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Here's the patch I have, against vanilla 2.4.2-pre1, with the
> pci_enable_device preferred changes included...
Well, I decided to bite the bullet and port my zerocopy starfire
changes to the official tree,
Hi Alan et. all
I'm not sure whether this is related to the ominous ps/2 mouse bug
you have been chasing, but this problem is 100% reproducible and
very annoying.
After upgrading my Asus A7V Bios from 1003 to 1005D, gpm no longer
receives any mouse events and the mouse doesn't work in text
On Wed, 7 Feb 2001, David Woodhouse wrote:
> [EMAIL PROTECTED] said:
> > On one of my linux boxen, that is used as an ISDN router after a 3
> > days of up time I get this:
>
> Read http://www.tux.org/lkml/#s4-3
>
> Particularly the "Don't even bother..." part.
The Call Trace was decoded by
New Concept in Gifting!
Join A Team Of 6 And 7 Figure Earners
The sole purpose of this Activity is to enable us to bless more people and to change
lives by helping others receive gifts, which will enable the receiver to share their
blessings with others!
* Gift $2000 to prosper over $16,000
Alexy wrote:
> > > How close is TCP_NOPUSH to behaving identically to TCP_CORK now?
>
> They have not so much of common.
>
> TCP_NOPUSH enables T/TCP and its presense used to mean that
> T/TCP is possible on this system. Linux headers cannot
> even contain TCP_NOPUSH.
But Tony Finch
On Wed, 7 Feb 2001, Linus Torvalds wrote:
> No. The optimization is entirely legal - but the fact that
> "constant_test_bit()" uses a "volatile unsigned int *" is the reason why
> gcc thinks it can't optimize it.
This thing did attract me somewhat and I decided to learn a little about
On Wednesday February 7, [EMAIL PROTECTED] wrote:
>
> This is a weird problem that I am looking at right. It seems to indicate a
> bug in the nfs server.
>
> I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2
> workstation. Everything works fine except that after a few
This is a weird problem that I am looking at right. It seems to indicate a
bug in the nfs server.
I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2
workstation. Everything works fine except that after a few reboots I start to
see the error messages like the following:
Dear all,
The board I used has two pieces of RAM. The virtual address start at 0x
and
0x0200 . One is 4 MB(0x ) and the other is 16 MB(0x0200 ).
But
orginal file is writted as the following. How could I modify this file to
match my
target board?
Green
> It appears that the loopback-hang parasite is alive and well in 2.4.1-ac5.
> I've done several tests and I thus provide the following information:
>
> The bug is independent of UP or SMP configured.. it hung both ways, but the
> box itself is UP.
>
> It appears to hang when internal
On Wed, 7 Feb 2001, Jason Ford wrote:
> Byron,
>
> I got your patch to compile in fine however it still exhibits the same
> behavior that the older patches did. It looks like the commands sent to the
> controller are still not working correctly as the new subsystem in the
> kernel was
I sent this oops to the file system and a raid maintainer asking for
more
info and received no response. Please let mw know if there is a better
place to send it.
I received a kernel oops in the file system layer on my dual PIII w/
software Raid5
running RedHat 6.2 with the redhat kernel
Earlier I reported error messages when I tried to eject
a Xircom CEM56 network card under Linux 2.4.x. (See below.
I also submitted this patch as a followup to that thread.)
Here is a patch which may not solve the underlying
problem but which does prevent the kernel from generating
an infinite
someone knows a good sendmail mailing list ? active like this one ?
thanks..
-
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/
Grover, Andrew wrote:
> Since you have a symtomatic system, if you're willing to do some testing to
> either prove or disprove your theory (that entering C2/C3 interrupts enabled
> helps things) I would greatly appreciate it.
Leaving interrupts enabled does help a little, but the machine is
The ServerWorks peer bus problem is still present on the 2.4.1 kernel. The
problem stems from the fact that there can be more than one secondary bus
for a given north bridge. For example, the Compaq Proliant DL580 has two
"root busses" coming off of a single north bridge. I'm including below
Byron,
I got your patch to compile in fine however it still exhibits the same
behavior that the older patches did. It looks like the commands sent to the
controller are still not working correctly as the new subsystem in the
kernel was rewritten.
This is the error I get in my messages file when
Here is a patch which may not solve the underlying
problem but which does prevent the kernel from
generating an infinite number of error messages
on "cardctl eject" and from hanging up on shutdown.
On Wednesday February 7, [EMAIL PROTECTED] wrote:
>
>
> On Wed, 7 Feb 2001, Christoph Hellwig wrote:
>
> > On Tue, Feb 06, 2001 at 12:59:02PM -0800, Linus Torvalds wrote:
> > >
> > > Actually, they really aren't.
> > >
> > > They kind of _used_ to be, but more and more they've moved away
Resolved! Running like a bought one now. Thanks Urban, you are so cool
that you should be in movies.
~NJ!~
> -Original Message-
> From: Urban Widmark [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 08, 2001 9:39 AM
> To: Jim Shaw
> Cc: [EMAIL PROTECTED]
> Subject: Re:
>> There are two entirely different things both called LBA.
>> Neither of them wastes any space.
> You sure?
Yes. One is the hardware disk access - all disk access is LBA
these days, certainly by Linux, but if the disk is small
one can also use CHS access, when it is old one has to use CHS.
"J . A . Magallon" wrote:
>
> On 02.07 Tigran Aivazian wrote:
> > Alan, Doug,
> >
> > If this is a known problem -- ignore. Otherwise, I will gladly assist as
> > much as you need.
> >
> > Just tried ac5 kernel and, behold (btw, why does serial console not work
> > anymore, I had to copy these
We are starting to look at setting up a test environment
for Linux on OS/390 platforms (probably using VM/VSE). Does anyone know of
any good mail-lists or
usenet groups et al that would be specific to this type of porting/running
on this platform?
Steve
-
To unsubscribe from this list: send
On Wednesday, February 07, 2001 04:35:32 PM + Tigran Aivazian <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> Under 2.4.1, after a little bit of running SPEC SFS (with NFSv3) I get
> these messages on the server:
>
> vs-13042: reiserfs_read_inode2: [0 1 0x0 SD] not found
> vs-13048: reiserfs_iget:
On Wednesday, February 07, 2001 12:31:43 PM -0500 Jeff McWilliams
<[EMAIL PROTECTED]> wrote:
> I'm having difficulty mounting a reiserfs partition after a power outage.
>
> This is 2.4.0-test9 compiled with reiserfs as a module, and
Which reiserfs version is this? Upgrading to the
On Wed, 7 Feb 2001 [EMAIL PROTECTED] wrote:
> I've compiled a number of 2.4.1 and 2.4.0 kernels (actually supports the 4GB
> RAM!!! Yay), and I have only one more problem to sort out. Under
> 2.4.x, the mount completes successfully, but 'ls /net' causes an OOPS: .
Try
On 02.07 Tigran Aivazian wrote:
> Alan, Doug,
>
> If this is a known problem -- ignore. Otherwise, I will gladly assist as
> much as you need.
>
> Just tried ac5 kernel and, behold (btw, why does serial console not work
> anymore, I had to copy these by hand):
>
> (scsi0) BRKADRINT
On Tue, Feb 06, 2001 at 05:01:46PM +0100, Udo A. Steinberg wrote:
> Dale Farnsworth wrote:
> >
> > However, if I enable the BIOS parameter "I/O Recovery Time", I can still
> > enable read caching without seeing any data corruption.
> > The lastest BIOS revision (1005C) enables "I/O Recovery
Tigran Aivazian <[EMAIL PROTECTED]> writes:
> Hi,
>
> Under 2.4.1, after a little bit of running SPEC SFS (with NFSv3) I get
> these messages on the server:
>
> vs-13042: reiserfs_read_inode2: [0 1 0x0 SD] not found
> vs-13048: reiserfs_iget: bad_inode. Stat data of (0 1) not found
> vs-13048:
Hi Jeff, l-k,
Here's my current diff resynced against ac5. This catches
all the remaining cases in drivers/net except for starfire
(which you posted a bigger patch for).
Oh, there's also a kmalloc change in macsonic.c that I've
had hanging around for a while.
If this looks ok, I'll split it
Alan Cox wrote:
>
> > I'm porting some software to Linux that requires use of a bidirectional,
> > named pipe. The architecture is as follows: A server creates a named pipe
>
> Pipes are not bidirectional in Linux. We follow traditional non stream
> behaviour
>
> > /dev/spx". I
On Wed, 7 Feb 2001, Jason Ford wrote:
> I see in the archives of this mailing list that someone was working on the
> aacraid driver for the 2.4 kernel however that post was almost 2 months old.
> I know Alan Cox denied inclusion of the driver due to the poor nature it was
> written for the 2.2
Peter Samuelson wrote:
> A more useful thing to fall out of the same hacking is loopback
> mounting -- i.e. the same filesystem mounted multiple places. In
> Linux-land I guess we call it 'mount --bind'.
>
> Peter
Does this kind of thing play nice with nfs and coda, in terms of
change
It appears that the loopback-hang parasite is alive and well in 2.4.1-ac5.
I've done several tests and I thus provide the following information:
The bug is independent of UP or SMP configured.. it hung both ways, but the
box itself is UP.
It appears to hang when internal buffers get filled. The
On Wed, Feb 07, 2001 at 06:44:34PM +0100, [EMAIL PROTECTED] wrote:
> > It's currently in LBA mode (I believe) and that, to my knowledge,
> > wastes the most space.
>
> There are two entirely different things both called LBA.
> Neither of them wastes any space.
You sure? I admit to not having
It looks like support for this is available at:
http://opensource.compaq.com/sourceforge/project/?group_id=13
-Jamey Hicks
-Original Message-
From: Adam J. Richter [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 07, 2001 1:08 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
On Wed, 07 Feb 2001 11:48:32 +0100, Stefan Majer <[EMAIL PROTECTED]> wrote:
> Hi All
>
> I installed a Adaptec Quad Port Ethernet Adapter called Quartet64 and
> after compiling 2.4.1
> with starfire support i got the following messages in syslog
>
> after
>
> ifconfig eth2 172.17.1.4
I see in the archives of this mailing list that someone was working on the
aacraid driver for the 2.4 kernel however that post was almost 2 months old.
I know Alan Cox denied inclusion of the driver due to the poor nature it was
written for the 2.2 tree. Every post that I have seen so far has
On Wed, 7 Feb 2001, [ISO-8859-1] Gérard Roudier wrote:
>
> You missed the newer statements about every piece of hardware being
> assumed to be hot-pluggable and all the hardware being under full control
> by CPU.
>
> You also missed the well known point that only device drivers are broken
>
On Wednesday, February 07, 2001 11:05:51 PM +0100 Xuan Baldauf
<[EMAIL PROTECTED]> wrote:
> Mhhh. It's a busy server from which I am about 700km away. I don't like to
> restart it now. (Especially because it cannot boot from hard disk, only
> from floppy disk, due to bios problems). But I'd be
On Wednesday February 7, [EMAIL PROTECTED] wrote:
>
> Hi,
> I have a strange problem on one of our server.
> I have 2.4.1 patched with ACLs 0.7.5 (from acl.bestbits.at) and some RAID +
> LVM volumes.
> At regular interval, NFS stops working (nfsd stops) and a stop/start of the
> NFS service
Alan, Doug,
If this is a known problem -- ignore. Otherwise, I will gladly assist as
much as you need.
Just tried ac5 kernel and, behold (btw, why does serial console not work
anymore, I had to copy these by hand):
(scsi0) BRKADRINT error(0x44):
Illegal Opcode in sequencer program
PCI
Chris Mason wrote:
> On Thursday, February 08, 2001 10:47:29 AM +1300 Chris Wedgwood
> <[EMAIL PROTECTED]> wrote:
>
> > these appear on your system every couple of days right? if so... are
> > you able to run with the fs mount notails for a couple of days and
> > see if you still experience
On Thursday, February 08, 2001 10:47:29 AM +1300 Chris Wedgwood
<[EMAIL PROTECTED]> wrote:
> these appear on your system every couple of days right? if so... are
> you able to run with the fs mount notails for a couple of days and
> see if you still experience these?
>
> my guess is you
You missed the newer statements about every piece of hardware being
assumed to be hot-pluggable and all the hardware being under full control
by CPU.
You also missed the well known point that only device drivers are broken
under Linux and that all the generic O/S code is just perfect. :-)
On Wed, 7 Feb 2001, Hugh Dickins wrote:
>
> The "(1< activate_page_nolock() compiled -O2 -march=i686 with egcs-2.91.66 (RH7.0
> kgcc), gcc-2.96-69 (RH7.0 gcc+fixes), gcc-2.97 (gcc-snapshot-20010207-1).
>
> None of those optimizes this: I believe the semantics of &quo
I'm trying to troubleshoot a failure with my Maxtor hard drive that I have
experienced consistantly, even in the 2.2.x kernels (I'm now running
2.2.1-test10, .config is attached). It detects all of my drives fine:
block: queued sectors max/low 126786kB/95090kB, 384 slots per queue
Uniform
Ivan Kokshaysky wrote:
> Mainly because there are driverless devices like display adapters,
> PCI bridges, or PCI devices with legacy drivers (IDE, for example).
Ok. It seems that all of those would have to interact with
the PCI code someplace. And that's were pci_enable_device()
could be
While attempting to port Linux to a new platform using a compiler other
then GCC I noticed that there appears to be a volatile missing on the
declaration of xtime in include/linux/sched.h. The compiler I am using
considers this to be an error. The following may help your problem.
Manfred Spraul writes:
> process 2 (on cpu 1)
> read(fd,buf,64kB).
> * reads the data
> * now it must wake up, but it will return from the syscall, thus
> wake_up_interruptible().
Oh, I see and thus the pre-kiovec case would be:
process 2 (on cpu 1)
read(fd,
On Wed, Feb 07, 2001 at 11:50:52AM -0800, Grant Grundler wrote:
> Can you explain why pci_assign_unassigned_resources()
> calls pdev_enable_device() for every PCI device instead
> of having each PCI *driver* call pci_enable_device()
> as part of driver initialization?
Mainly because there are
"David S. Miller" wrote:
>
> Manfred Spraul writes:
> > * if you run 2 instances on a dual cpu P II/350 it's a big win, but if
> > you run only one instance, then the bw_pipe processes will jump from one
> > cpu to the other and it's only a small improvement (~+15%).
>
>
On Wed, 7 Feb 2001, Matthias Schniedermeyer wrote:
> > > now that -ac grows that huge, could you put out incremental patches?
> >
> > Takes me too much time. But if anyone else wants to, go ahead
>
> This is what i use to diff 2 different kernels
>
> - snip -
>...
> - snip -
>
> This takes about
Dear Mr. Molnar,
Could you please take a look at this issue ? Also, if you could cc: me on a
possible reply, since I am not subscribed to the mailing list...
Thanks in advance,
Christoph Schmitz
---
The symptom:
On Mon, 05 Feb 2001, Peter Horton wrote:
> I've found the cause of silent disk corruption on my A7V motherboard,
> and it might affect all boards with the same North bridge (KT133 etc).
...
> [1] the BIOS appears to let you change the option but it defaults the
> option the moment you leave
Thanks for the trouble.
Your patch had some problem in the maxiradio_radio_init function as
pci_register_driver returns the number of devices found and not 0 when
succesful. I fixed it and here is my patch against the original driver.
Diff output is still weird.
---
> > now that -ac grows that huge, could you put out incremental patches?
>
> Takes me too much time. But if anyone else wants to, go ahead
This is what i use to diff 2 different kernels
- snip -
diffkernel)
mount none /d/kernel -t ramfs
cd /d/kernel
tar
On Wed, 7 Feb 2001, Alan Cox wrote:
> > Iff CONFIG_BLK_DEV_IDECS is set then yes, doing schedule is better.
> > But I do not see any benefit in doing
> >
> > unsigned long timeout = jiffies + ((HZ + 19)/20) + 1;
> > while (0 < (signed long)(timeout - jiffies));
>
> On that bit we agree.
What
Manfred Spraul writes:
> * if you run 2 instances on a dual cpu P II/350 it's a big win, but if
> you run only one instance, then the bw_pipe processes will jump from one
> cpu to the other and it's only a small improvement (~+15%).
wake_up_interruptible_sync is meant specifically to avoid
I finished my single copy pipe/fifo implementation.
Main changes:
* it's more a rewrite of pipe_read() and pipe_write().
Both functions were a nightmare of nested loops and gotos.
I wrote a test app - with the right timing multiple writers on a fifo
can race and then they busy loop in the
> I stand by my statement. PCI devices that require resources are
> required to provide read/write registers indicating these resources
> whether or not the enable bits are set. This is mandatory.
And the assignment of those resources is done by pci_enable_device. So
looking at the irq data or
1 - 100 of 456 matches
Mail list logo
