> General bitching pisses me off, especially when you are dead wrong.
A little maturity goes a long way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
General bitching pisses me off, especially when you are dead wrong.
A little maturity goes a long way.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
> What still stands out is that exactly _zero_ people have reported the same
> problem with non VIA chipset Athlons.
This might be grasping at straws I remember VIA problem in the "good old
days" of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write
settings that would cause
What still stands out is that exactly _zero_ people have reported the same
problem with non VIA chipset Athlons.
This might be grasping at straws I remember VIA problem in the good old
days of Socket 7 with CPU/PCI Prefetches and especially Read-around-Write
settings that would cause issues
> o Fix ppp memory corruption (Kevin Buhr)
> | Bizzarely enough a direct re-invention of a 1.2 ppp bug
Could this explain my MPPP skb corruption I've reported since 2.3.x?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
o Fix ppp memory corruption (Kevin Buhr)
| Bizzarely enough a direct re-invention of a 1.2 ppp bug
Could this explain my MPPP skb corruption I've reported since 2.3.x?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
> I suspect it's easier to just make the PCI layer call the probe function
> in that order, instead of working around it in your driver. Jeff?
Would 'pci=reverse' do the trick already?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
I suspect it's easier to just make the PCI layer call the probe function
in that order, instead of working around it in your driver. Jeff?
Would 'pci=reverse' do the trick already?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Umm.. where is it located? :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Umm.. where is it located? :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
| Since that time, about 1986, I learned that there is a whole cottage
| industry of going through old, but not too old, patents and seeing how
| they can be misconstrued to apply to current technology, buying the
| patent for cheap, and then threatening "infringers". More or less
| an extortion
| Since that time, about 1986, I learned that there is a whole cottage
| industry of going through old, but not too old, patents and seeing how
| they can be misconstrued to apply to current technology, buying the
| patent for cheap, and then threatening "infringers". More or less
| an extortion
| Since that time, about 1986, I learned that there is a whole cottage
| industry of going through old, but not too old, patents and seeing how
| they can be misconstrued to apply to current technology, buying the
| patent for cheap, and then threatening "infringers". More or less
| an extortion
| Since that time, about 1986, I learned that there is a whole cottage
| industry of going through old, but not too old, patents and seeing how
| they can be misconstrued to apply to current technology, buying the
| patent for cheap, and then threatening "infringers". More or less
| an extortion
| > Problem still exists, diffed to last kernel:
| Yes. But everything works for you, no? Including USB?
Mmmhmm..
| The problem is that you have this routing table entry:
|
| 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/
|
| which is really for the USB chip (PCI id 00:01.2), and which
| Could people that had problems with SiS interrupt handling before please
| give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot
| of pirq tables from people, and Martin Diehl put them together with the
| hardware specs to come up with what looks to be the "final and
| Problem still exists, diffed to last kernel:
| Yes. But everything works for you, no? Including USB?
Mmmhmm..
| The problem is that you have this routing table entry:
|
| 00:01 slot=00 0:62/1eb8 1:00/ 2:00/ 3:00/
|
| which is really for the USB chip (PCI id 00:01.2), and which
| 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?
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
| Your "link" values are in the range 1-4. Which makes perfect sense, but
| that's absolutely _not_ what the Linux SiS routing code expects (the code
| seems to expect them to be ASCII 'A' - 'D').
| It looks very much like "pirq_sis_get()" and "pirq_sis_set()" in
| arch/i386/kernel/pci-irq.c are
| 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?
| o Set last_rx on ppp_generic (Jeff Garzik)
Is this related to my MPPP crashes or is this an unrelated fix?
-
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/
| o Set last_rx on ppp_generic (Jeff Garzik)
Is this related to my MPPP crashes or is this an unrelated fix?
-
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/
I took out my can of RAID and went bug hunting.
The kernel was always crashing in this subroutine and the comment near the
list walk clued me in.
I've run this fixed kernel all night and can no longer make it OOPS from a
racy list walk.
It may be overkill to use ppp_lock instead of the finer
I took out my can of RAID and went bug hunting.
The kernel was always crashing in this subroutine and the comment near the
list walk clued me in.
I've run this fixed kernel all night and can no longer make it OOPS from a
racy list walk.
It may be overkill to use ppp_lock instead of the finer
Always the glutton for punishment, I did it again tonite. A different oops
now.
See my last message for prior info.
ksymoops 2.3.7 on i586 2.4.1-pre8. Options used
-v /usr/src/linux/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o
Always the glutton for punishment, I did it again tonite. A different oops
now.
See my last message for prior info.
ksymoops 2.3.7 on i586 2.4.1-pre8. Options used
-v /usr/src/linux/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o
I reported this a few months ago without much details and the machine
involved died shortly after which made me think that
this oops was merely bad hardware. This is a brand new machine and the opps
popped up again. Thankfully I armed myself
with a serial console and captured this beast.
I reported this a few months ago without much details and the machine
involved died shortly after which made me think that
this oops was merely bad hardware. This is a brand new machine and the opps
popped up again. Thankfully I armed myself
with a serial console and captured this beast.
| 2.2.18-pre26 was compiled with gcc 2.91.66 (kgcc).
| 2.4.0-test12-pre7 was compiled with gcc 2.95.3.
That's your answer right there.
GCC 2.95.3 compiles much slower than kgcc.
Rerun the 2.4.0 with kgcc to be fair. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> By the way, does 2.2.x behave in the same way?
No. 2.2.x and if I remember right, even 2.0.x all get it right.
> I'm interested in lspci -vvx outputs for all the cases and also in effect
> of "pci=bios", "pci=conf1" and "pci=conf2" switches.
Will do.
-
To unsubscribe from this list: send
> at the kernel command line. I admit it isn't a nice solution, but I
> don't know any way which would be 100% reliable on all machines
> and your machine is the only case I know about where the current
> algorithm breaks.
Me me me me. :)
I have an odd situation.. in 2.4.x on my old P60, if I
at the kernel command line. I admit it isn't a nice solution, but I
don't know any way which would be 100% reliable on all machines
and your machine is the only case I know about where the current
algorithm breaks.
Me me me me. :)
I have an odd situation.. in 2.4.x on my old P60, if I choose
By the way, does 2.2.x behave in the same way?
No. 2.2.x and if I remember right, even 2.0.x all get it right.
I'm interested in lspci -vvx outputs for all the cases and also in effect
of "pci=bios", "pci=conf1" and "pci=conf2" switches.
Will do.
-
To unsubscribe from this list: send the
| > It screams like a banshee when enabled.
| yup.
| How annoying but interesting. You'd think they'd mention it (ASUS). Do you have
|this
| website anywhere still?
On my hard drive :)
I will repost it soon, hopefully later tonite.
Keep an eye out on http://www.mojomofo.com
| > ASUS P5A with delayed transactions enabled?
| Oh, you know this critter? I'm assuming disabling delayed transactions fixes the
| speaker solos?
I used to have a website dedicated to all the quirks that motherboard had. :)
It's either delayed transactions or passive release that
| ASUS P5A with delayed transactions enabled?
| Oh, you know this critter? I'm assuming disabling delayed transactions fixes the
| speaker solos?
I used to have a website dedicated to all the quirks that motherboard had. :)
It's either delayed transactions or passive release that causes
The last version I've spotted was for mid-2.2 and was filled with gcc 2.7-isms
in the assembler code. I was curious if anyone has updated this to version 2.4
at all because it makes all the difference in the world for me with my P60. Now
that the memcpy stuff is somewhat modularized (with the
The last version I've spotted was for mid-2.2 and was filled with gcc 2.7-isms
in the assembler code. I was curious if anyone has updated this to version 2.4
at all because it makes all the difference in the world for me with my P60. Now
that the memcpy stuff is somewhat modularized (with the
43 matches
Mail list logo
