Device 00:01.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTC: link 0x03, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTD: link 0x04, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
Your "link" values are
A minor problem here - module_init(irda_proto_init) got bracketed
by #ifdef MODULE and became ineffective if compiled without modules.
-- Pete
diff -ur -X dontdiff linux-2.4.1-pre11/net/irda/af_irda.c
linux-2.4.1-pre11-p3/net/irda/af_irda.c
--- linux-2.4.1-pre11/net/irda/af_irda.cSat
-Original Message-
From: Chris Evans [mailto:[EMAIL PROTECTED]]
Sent: Monday, 29 January 2001 13:04
To: Tony Young
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Linux Disk Performance/File IO per process
On Mon, 29 Jan 2001 [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
My ASUS SP97-V complains about PIRQ conflicts so I gave this a whirl
(It is SiS 5598 based)
Your pirq values are different - they are in the 0x41-0x44 range, like the
old SiS router code assumes. Except for one that has value 0x62, which the
old
I am running a web server under the new 2.4.0 kernel and am experiencing
some intermittent odd behavior from the kernel. The machine will sometimes
go through cycles where network response becomes slow even though top
reports over 60% idle CPU time. When this is happening ping goes from
On Sun, 28 Jan 2001, Tim Hockin wrote:
In reading the PIRQ specs, and making it work for our board, I thought
about this. PIRQ states that link is chipset-dependant. No chipset that I
have seen specifies what link should be. So, as this case demonstrates, it
may be 'A' - the value the
snip from dmesg:
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 00:09.0
got res[1000:10ff] for resource 0 of ATI Technologies Inc 3D
Rage I/II 215GT [Mach64 GT]
Limiting direct PCI/PCI transfers.
What does this mean?
The video card should be using irq 10
From: Linus Torvalds [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Robert Siemer wrote:
(...) that's really interesting..
Device 00:01.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTB: link 0x02, irq mask 0x1eb8 [3,4,5,7,9,10,11,12]
INTC: link 0x03,
In mailing-lists.linux-kernel, you wrote:
I am running a web server under the new 2.4.0 kernel and am experiencing
some intermittent odd behavior from the kernel. The machine will sometimes
go through cycles where network response becomes slow even though top
reports over 60% idle CPU time.
On Mon, 29 Jan 2001, Robert Siemer wrote:
and see if that changes the behaviour.
It doesn't. A diff from the kernel output is following. Maybe it
helps...
Actually, this looks like it _did_ fix something - now the kernel no
longer thinks there is a IRQ routing conflict, so it does
The server in question is running the tulip driver. dmesg reports:
Linux Tulip driver version 0.9.13 (January 2, 2001)
I have seen this same behavior on a couple of my servers running 3com
3c905c adaptors as well.
The last time I was experiencing it I rebooted the system and it didn't
The _modinst_post_pcmcia target was added to Makefile in 2.4.0-test6-pre3,
August 5 2000. It was a compatibility aid until people upgraded to a
version of pcmcia-cs that used modprobe instead of insmod. Five months
later, it is time to remove _modinst_post_pcmcia.
Linus, please apply at any
On Sun, 28 Jan 2001, Mo McKinlay wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, H. Peter Anvin ([EMAIL PROTECTED]) wrote:
Hello people... the original question was: can lost+found be
*renamed*, i.e. does the tools (e2fsck c) use "/lost+found" by name,
or by inode?
All,
I work for a company that develops a systems and performance management
product for Unix (as well as PC and TANDEM) called PROGNOSIS. Currently we
support AIX, HP, Solaris, UnixWare, IRIX, and Linux.
I've hit a bit of a wall trying to expand the data provided by our Linux
solution - I
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
| How about you try adding the line
| pirq = (pirq-1) 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
| How about you try adding the line
| pirq = (pirq-1) 3;
| at the top of both pirq_sis_get() and pirq_sis_set() (with my "alternate"
| SiS routines). What happens then?
From: Linus Torvalds [EMAIL PROTECTED]
On Mon, 29 Jan 2001, Robert Siemer wrote:
and see if that changes the behaviour.
It doesn't. A diff from the kernel output is following. Maybe it
helps...
Actually, this looks like it _did_ fix something - now the kernel no
longer
H. Peter Anvin writes:
Hello people... the original question was: can lost+found be
*renamed*, i.e. does the tools (e2fsck c) use "/lost+found" by name,
or by inode? As far as I know it always uses the same inode number
(11), but I don't know if that is anywhere enforced.
Bzzt. /lost+found
On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
| Which one was it you got a PIRQ conflict for before? as it te device at
| 00:01.00 with the strange "0x62" entry?
Yes.
You've got the pirq setup from hell.
Mind doing that "dump_pirq" thing, preferably run on an _unmodified_ 2.4.0
kernel (ie
David Lang writes:
I am behind a raptor firewall and ran the test that David M posted a
couple days ago and was able to sucessfully connect to his test machine.
so either raptor tolorates ECN (at least in the verion I am running) or
the test was not valid.
Did you actually list a
On Mon, 29 Jan 2001, Robert Siemer wrote:
Further I always see '09' in the Configuration Space at Interrupt_Line
(0x3c) for the 00:01.2 USB Controller. But 2.4.0 says:
Interrupt: pin A routed to IRQ 12
while 2.4.0-test9 states:
Interrupt: pin A routed to IRQ 9
Ahhah!
I bet it's the
Linus, please apply v2.4.0.
ipt_TOS checksum calculations were completely broken, causing bad csum
packets. Whoever implemented it didn't understand the code it was
copied from.
This fixes the problem (tested in userspace against all TOS changes).
Rusty.
--
Premature optmztion is rt of all
James Sutherland writes:
Except you can detect and deal with these "PMTU black holes". Just as you
should detect and deal with ECN black holes. Maybe an ideal Internet
wouldn't have them, but this one does. If you can find an ideal Internet,
go code for it: until then, stick with the
401 - 423 of 423 matches
Mail list logo
