Dave Jones wrote:
On Wed, Dec 13, 2006 at 10:47:32PM -0500, Daniel Drake wrote:
> In amd64-agp.c, would it be dangerous to remove the "aperture base > 4G"
> thing and instead simply only read the rightmost 7 bits to ensure the
> aperture base is always in range
Dave Jones wrote:
On Wed, Dec 13, 2006 at 10:47:32PM -0500, Daniel Drake wrote:
In amd64-agp.c, would it be dangerous to remove the aperture base 4G
thing and instead simply only read the rightmost 7 bits to ensure the
aperture base is always in range? (This is coming from someone
Hi Dave,
I'm working on a solution for
http://bugzilla.kernel.org/show_bug.cgi?id=6350
Certain BIOSes are screwing with the K8 aperture base value. However,
these systems work after booting into windows and then rebooting into Linux.
It originally appeared to be a bug specific to asrock
Hi Dave,
I'm working on a solution for
http://bugzilla.kernel.org/show_bug.cgi?id=6350
Certain BIOSes are screwing with the K8 aperture base value. However,
these systems work after booting into windows and then rebooting into Linux.
It originally appeared to be a bug specific to asrock
Adrian Bunk wrote:
Daniel Drake (1):
PCI: VIA IRQ quirk behaviour change
Please drop this one, Alan isn't 100% on it and is working on getting a
better fix into mainline
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Adrian Bunk wrote:
Daniel Drake (1):
PCI: VIA IRQ quirk behaviour change
Please drop this one, Alan isn't 100% on it and is working on getting a
better fix into mainline
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Andrew Morton wrote:
What's the relationship between this patch and the fixes in this area in -mm?
I was unaware of those.
The first patch in -mm is obviously broken but is fixed by the 2nd one.
The combination of both looks OK to me. I'm happy for either approach to
be merged, it will make
Andrew Morton wrote:
What's the relationship between this patch and the fixes in this area in -mm?
I was unaware of those.
The first patch in -mm is obviously broken but is fixed by the 2nd one.
The combination of both looks OK to me. I'm happy for either approach to
be merged, it will make
if
an external kernel module is being built. The behaviour in other situations
is unmodified.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
Index: linux-2.6.19/scripts/Kbuild.include
===
--- linux-2.6.19.orig/scripts/Kbuild.include
+++
if
an external kernel module is being built. The behaviour in other situations
is unmodified.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux-2.6.19/scripts/Kbuild.include
===
--- linux-2.6.19.orig/scripts/Kbuild.include
+++ linux
Tejun Heo wrote:
Hello, Alan.
We've been getting bug reports from sata_via users for quite sometime
now. The first IRQ driven command (IDENTIFY) times out and thus device
detection fails. The following patch seems to fix it for many users.
Tejun Heo wrote:
Hello, Alan.
We've been getting bug reports from sata_via users for quite sometime
now. The first IRQ driven command (IDENTIFY) times out and thus device
detection fails. The following patch seems to fix it for many users.
Bart, any word on this? I know you're busy but it would be much appreciated if
you could comment, even if it is hurling abuse ;)
Thanks.
Daniel Drake wrote:
Hows this? I don't have any hardware with two VIA controllers, however I
have tested this on a pc which has a single vt8233a controller
Bart, any word on this? I know you're busy but it would be much appreciated if
you could comment, even if it is hurling abuse ;)
Thanks.
Daniel Drake wrote:
Hows this? I don't have any hardware with two VIA controllers, however I
have tested this on a pc which has a single vt8233a controller
hardware with two VIA controllers, however I have
tested this on a pc which has a single vt8233a controller.
---
Support multiple controllers in the via82cxxx IDE driver
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
--- linux/drivers/ide/pci/via82cxxx.c.orig 2005-08-31 01:32:05.0
Hi,
Stelian Pop wrote:
Confirmed on an Apple Powerbook too.
For reference, the (already reverted) patch which needs to be applied is
below.
Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
Index: linux-2.6.git/drivers/pci/setup-res.c
Hi,
Stelian Pop wrote:
Confirmed on an Apple Powerbook too.
For reference, the (already reverted) patch which needs to be applied is
below.
Signed-off-by: Stelian Pop [EMAIL PROTECTED]
Index: linux-2.6.git/drivers/pci/setup-res.c
hardware with two VIA controllers, however I have
tested this on a pc which has a single vt8233a controller.
---
Support multiple controllers in the via82cxxx IDE driver
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
--- linux/drivers/ide/pci/via82cxxx.c.orig 2005-08-31 01:32:05.0 +0100
Stephen Hemminger wrote:
You have a version of the Marvell Yukon that was affected
by a fix in 2.6.13.
skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
Both the skge and sk98lin driver were fixed to check for this.
Without the fix, the chip will be in the wrong power mode.
The version
Stephen Hemminger wrote:
You have a version of the Marvell Yukon that was affected
by a fix in 2.6.13.
skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9
Both the skge and sk98lin driver were fixed to check for this.
Without the fix, the chip will be in the wrong power mode.
The version
this, and Sergey Vlasov
recently asked the same question on LKML. If the patch isn't acceptable then
please at least say _something_ :)
Thanks!
--
From: Mathias Kretschmer <[EMAIL PROTECTED]>
Add VIA VT6410 IDE support
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff -Naru a/dri
Forwarding on, please reply-to-all in future.
Steve Kieu wrote:
Hi all,
I have "fixed" the problem in a very wierd way.Reading
your post I thought maybe when removing the driver
itself it set some bit incorrectly. Then I decided to
do:
Boot with init=/bin/bash so bypass all other things.
Hi Stephen,
This looks like an issue I reported previously. After you use a recent skge,
you can't use any older drivers or the windows driver, but skge still works
fine every time.
http://marc.theaimsgroup.com/?l=linux-netdev=112268414417743=2
The Gentoo bug report is here:
Steve Kieu wrote:
Are you using skge or sk98lin?
sk98lin
thanks
Can you test the new skge driver instead? If that one is broken then we
probably have more chance of getting it fixed :)
Thanks,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Steve Kieu wrote:
Ok it sound wierd enough to assume that the latest
kernel 2.6.13 ethernet driver has done something wrong
with the NIC and sustain the condition after reboot or
turn off the machine.
Here is my configuration.
Laptop Asus A4500d. dmesg shows:
eth0: Yukon Gigabit Ethernet
Steve Kieu wrote:
Are you using skge or sk98lin?
sk98lin
thanks
Can you test the new skge driver instead? If that one is broken then we
probably have more chance of getting it fixed :)
Thanks,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Steve Kieu wrote:
Ok it sound wierd enough to assume that the latest
kernel 2.6.13 ethernet driver has done something wrong
with the NIC and sustain the condition after reboot or
turn off the machine.
Here is my configuration.
Laptop Asus A4500d. dmesg shows:
eth0: Yukon Gigabit Ethernet
Hi Stephen,
This looks like an issue I reported previously. After you use a recent skge,
you can't use any older drivers or the windows driver, but skge still works
fine every time.
http://marc.theaimsgroup.com/?l=linux-netdevm=112268414417743w=2
The Gentoo bug report is here:
Forwarding on, please reply-to-all in future.
Steve Kieu wrote:
Hi all,
I have fixed the problem in a very wierd way.Reading
your post I thought maybe when removing the driver
itself it set some bit incorrectly. Then I decided to
do:
Boot with init=/bin/bash so bypass all other things.
this, and Sergey Vlasov
recently asked the same question on LKML. If the patch isn't acceptable then
please at least say _something_ :)
Thanks!
--
From: Mathias Kretschmer [EMAIL PROTECTED]
Add VIA VT6410 IDE support
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
diff -Naru a/drivers/ide/pci/via82cxxx.c b
Hi,
If there are no known issues it would be nice to push this for inclusion in
2.6.14. The relevant patches from -mm are named
ppp_mppe-add-ppp-mppe-encryption-module.patch and
ppp_mppe-add-ppp-mppe-encryption-module-update.patch
Judging by the feedback I get from Gentoo users, there is
Tim Weippert wrote:
As this is an Server, i don't even use cpufreq on this machine. So it
think this isn't the same problem ...
Maybe you could post your experiences here:
http://bugzilla.kernel.org/show_bug.cgi?id=5133
Daniel
-
To unsubscribe from this list: send the line
Tim Weippert wrote:
As this is an Server, i don't even use cpufreq on this machine. So it
think this isn't the same problem ...
Maybe you could post your experiences here:
http://bugzilla.kernel.org/show_bug.cgi?id=5133
Daniel
-
To unsubscribe from this list: send the line
Hi,
If there are no known issues it would be nice to push this for inclusion in
2.6.14. The relevant patches from -mm are named
ppp_mppe-add-ppp-mppe-encryption-module.patch and
ppp_mppe-add-ppp-mppe-encryption-module-update.patch
Judging by the feedback I get from Gentoo users, there is
Hi,
Tim Weippert wrote:
i have read some postings concerning the following Kernel Messages:
Aug 26 18:04:01 montdsnsu3 kernel: grep[11619] general protection
rip:2aaaed43 rsp:7f9c0740 error:0
Aug 26 18:08:02 montdsnsu3 kernel: ping[14867] general protection
rip:2aaaed43
Hi,
Tim Weippert wrote:
i have read some postings concerning the following Kernel Messages:
Aug 26 18:04:01 montdsnsu3 kernel: grep[11619] general protection
rip:2aaaed43 rsp:7f9c0740 error:0
Aug 26 18:08:02 montdsnsu3 kernel: ping[14867] general protection
rip:2aaaed43
Nigel Rantor wrote:
Who should I be talking to wrt to the irq 11: nobody cared issue?
I'm happy to provide as much info as possible but need to know what info
is required.
I'm happily running 2.6.7, tried the latest and greatest (2.6.12) and
found the problem, then started by looking at
Nigel Rantor wrote:
Who should I be talking to wrt to the irq 11: nobody cared issue?
I'm happy to provide as much info as possible but need to know what info
is required.
I'm happily running 2.6.7, tried the latest and greatest (2.6.12) and
found the problem, then started by looking at
Hi Jeff,
Jeff Garzik wrote:
I finally got around to creating something that has been missing since
BitKeeper disappeared, and something that Andrew has been wanting
from me for a while: an amalgamation of all the libata-dev branches
that I maintain internally.
You are missing two
Hi Jeff,
Jeff Garzik wrote:
I finally got around to creating something that has been missing since
BitKeeper disappeared, and something that Andrew has been wanting
from me for a while: an amalgamation of all the libata-dev branches
that I maintain internally.
You are missing two
CaT wrote:
1. Alan Cox's IDE driver that was included in his ac patchset, which
seems to have died at 2.6.11ac7.
Alan's driver has been merged into 2.6.13. You can get the up-to-date
Wooo!
patches here:
CaT wrote:
1. Alan Cox's IDE driver that was included in his ac patchset, which
seems to have died at 2.6.11ac7.
2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
It lived a brief but noted life before being taken out without any
reason (that I spotted) in
CaT wrote:
1. Alan Cox's IDE driver that was included in his ac patchset, which
seems to have died at 2.6.11ac7.
2. A brief visit from a SCSI IDE driver in Andrew Mortons mm patchset.
It lived a brief but noted life before being taken out without any
reason (that I spotted) in
CaT wrote:
1. Alan Cox's IDE driver that was included in his ac patchset, which
seems to have died at 2.6.11ac7.
Alan's driver has been merged into 2.6.13. You can get the up-to-date
Wooo!
patches here:
Joseph Fannin wrote:
I haven't seen any real changes in NTFS support in the kernel since
the mid-2.5 series. Is there somewhere else I should be looking?
The development tree is here:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/aia21/ntfs-2.6-devel.git;a=summary
Right now, I
Joseph Fannin wrote:
I haven't seen any real changes in NTFS support in the kernel since
the mid-2.5 series. Is there somewhere else I should be looking?
The development tree is here:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/aia21/ntfs-2.6-devel.git;a=summary
Right now, I
Kristoffer wrote:
why?:
Since LUFS is no longer maintained and FUSE is. since to use the LUFIS
bridge you have to install LUFS,
This is not true. lufis is a compatibility layer on top of FUSE which provides
the same API as lufs (thereby allowing you to load lufs modules into fuse). It
does
Kristoffer wrote:
why?:
Since LUFS is no longer maintained and FUSE is. since to use the LUFIS
bridge you have to install LUFS,
This is not true. lufis is a compatibility layer on top of FUSE which provides
the same API as lufs (thereby allowing you to load lufs modules into fuse). It
does
Alan Cox wrote:
What do the other reports look like ?
Here's one:
http://forums.gentoo.org/viewtopic-t-361718-highlight-irqpoll.html
This possibly suggests that the irqpoll patch actually caused a "nobody cared"
which wasn't there previously. (Now that I have looked closer at the patch, I
Alan Cox wrote:
Without the parameters it has exactly zero effect on the operation of
the kernel, the algorithms and the behaviour. So something odd is afoot
if its causing gentoo breakages.
Thats what I thought, yet it seems to be the difference between mouse and no
mouse in this case.
Alan Cox wrote:
What do the other reports look like ?
Here's one:
http://forums.gentoo.org/viewtopic-t-361718-highlight-irqpoll.html
This possibly suggests that the irqpoll patch actually caused a nobody cared
which wasn't there previously. (Now that I have looked closer at the patch, I
Alan Cox wrote:
Without the parameters it has exactly zero effect on the operation of
the kernel, the algorithms and the behaviour. So something odd is afoot
if its causing gentoo breakages.
Thats what I thought, yet it seems to be the difference between mouse and no
mouse in this case.
Hi,
I recently added the irqpoll patch to Gentoo's 2.6.12 kernels, using this patch:
http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2700_irqpoll.patch
Since then, I've had a few reports of minor breakage, but this is the first
one I've been able to get full info on.
Hans-Christian
Hi,
I recently added the irqpoll patch to Gentoo's 2.6.12 kernels, using this patch:
http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.12/2700_irqpoll.patch
Since then, I've had a few reports of minor breakage, but this is the first
one I've been able to get full info on.
Hans-Christian
Adrian,
Adrian Bunk wrote:
util-linux 2.13-pre1 is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux/testing/util-linux-2.13-pre1.tar.gz
Any comments on the mount patch I sent to you?
Attaching it again now. Please apply.
Thanks,
Daniel
From: Daniel Drake <[EMAIL PROTEC
Adrian,
Adrian Bunk wrote:
util-linux 2.13-pre1 is available at
ftp://ftp.kernel.org/pub/linux/utils/util-linux/testing/util-linux-2.13-pre1.tar.gz
Any comments on the mount patch I sent to you?
Attaching it again now. Please apply.
Thanks,
Daniel
From: Daniel Drake [EMAIL PROTECTED
Otto Meier wrote:
My question is also are these features (NCQ/TCQ) and the heigher
datarate be supported by this
modification? or is only the basic feature set of sata 150 TX4 supported?
NCQ support is under development. Search the archives for Jens Axboe's recent
patches to support this. I
Otto Meier wrote:
This card use the sata chip pdc 40718 (as of my card)
the lastest sata_promise kernel with sata promise patch driver doesn't
recognise
this card.
I added the following line to static struct pci_device_id
pdc_ata_pci_tbl[] in sata_promise.c:
{
Otto Meier wrote:
This card use the sata chip pdc 40718 (as of my card)
the lastest sata_promise kernel with sata promise patch driver doesn't
recognise
this card.
I added the following line to static struct pci_device_id
pdc_ata_pci_tbl[] in sata_promise.c:
{
Otto Meier wrote:
My question is also are these features (NCQ/TCQ) and the heigher
datarate be supported by this
modification? or is only the basic feature set of sata 150 TX4 supported?
NCQ support is under development. Search the archives for Jens Axboe's recent
patches to support this. I
Pete, Rusty,
I found a snippet of a previous discussion of yours here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/2901.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html
Did anything become of this issue?
A Gentoo user has reported what appears to be the same
Pete, Rusty,
I found a snippet of a previous discussion of yours here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/2901.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/0768.html
Did anything become of this issue?
A Gentoo user has reported what appears to be the same
Hi Alexander,
Alexander Fieroch wrote:
Alexander Fieroch wrote:
http://dlsvr01.asus.com/pub/ASUS/lan/marvell/8053/8053_others2.zip
Oh, that driver is very old. Here is the latest one which is working
with the current kernel:
Hi Alexander,
Alexander Fieroch wrote:
Alexander Fieroch wrote:
http://dlsvr01.asus.com/pub/ASUS/lan/marvell/8053/8053_others2.zip
Oh, that driver is very old. Here is the latest one which is working
with the current kernel:
Manfred Spraul wrote:
Autsch.
Yes, you are right. Sorry for that, I should have reread the patch once
more.
No problem :)
I've been running v0.38 since my last mail. No problems at all.
Thanks for your continued work on the driver.
Daniel
-
To unsubscribe from this list: send the line
Manfred Spraul wrote:
Autsch.
Yes, you are right. Sorry for that, I should have reread the patch once
more.
No problem :)
I've been running v0.38 since my last mail. No problems at all.
Thanks for your continued work on the driver.
Daniel
-
To unsubscribe from this list: send the line
Martin Povolný wrote:
For me it works with 20319, but I don't understand the difference
between different settings.
20319 is 4 port SATA.
2037x is 2 port SATA, optionally with 1 PATA port
20619 is 4 port PATA
So I believe 20319 is the correct option.
Jeff, the chip on the TX4200 is actually
Martin Povolný wrote:
For me it works with 20319, but I don't understand the difference
between different settings.
20319 is 4 port SATA.
2037x is 2 port SATA, optionally with 1 PATA port
20619 is 4 port PATA
So I believe 20319 is the correct option.
Jeff, the chip on the TX4200 is actually
Hi Martin,
Martin Povolný wrote:
We are succesfully running patched sata_promise with 3 disks in a
raid5/raid1 setup. (Patched against ubuntu linux-image 2.6.11-1-686
package.)
Could you please either send in your patch, or tell me which board_ setting
(2037x/20319/20619) the device ID table
Hi,
I recieved an email from someone claiming to be stuck with Linux 2.4, due to
relying on a Promise TX4200 disk controller (using the fdsata driver from
promise's website, which is 2.4-only):
:01:09.0 RAID bus controller: Promise Technology, Inc.: Unknown device
3519 (rev 02)
Hi,
I recieved an email from someone claiming to be stuck with Linux 2.4, due to
relying on a Promise TX4200 disk controller (using the fdsata driver from
promise's website, which is 2.4-only):
:01:09.0 RAID bus controller: Promise Technology, Inc.: Unknown device
3519 (rev 02)
Hi Martin,
Martin Povolný wrote:
We are succesfully running patched sata_promise with 3 disks in a
raid5/raid1 setup. (Patched against ubuntu linux-image 2.6.11-1-686
package.)
Could you please either send in your patch, or tell me which board_ setting
(2037x/20319/20619) the device ID table
Daniel Drake wrote:
After applying the v0.38 patch, I can't get any network at all. DHCP
fails to get an IP. v0.37 works fine.
Tracked it down. (sorry for linewraps)
+#define DEV_NEED_TIMERIRQ 0x0001 /* set the timer irq flag in the irq
mask */
+#define DEV_NEED_LINKTIMER 0x0002
Hi,
Manfred Spraul wrote:
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
Please
Hi,
Manfred Spraul wrote:
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
This
Hi,
Manfred Spraul wrote:
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
This
Hi,
Manfred Spraul wrote:
Attached is a patch that modifies the tx interrupt handling of the
nForce nic. It's part of the attempts to figure out what causes the nic
hangs (see bug 4552).
The change is experimental: It affects all nForce versions. I've tested
it on my nForce 250-Gb.
Please
Daniel Drake wrote:
After applying the v0.38 patch, I can't get any network at all. DHCP
fails to get an IP. v0.37 works fine.
Tracked it down. (sorry for linewraps)
+#define DEV_NEED_TIMERIRQ 0x0001 /* set the timer irq flag in the irq
mask */
+#define DEV_NEED_LINKTIMER 0x0002
Ludovic Drolez wrote:
> I recently had to boot a brand new system using a Marvel Yukon2 NIC
> (sk98lin) driver which is not supported by the latest kernel (pci ids =
> 11ab:4361).
>
> So I compiled the GPLed driver available from Syskonnect,
>
Ludovic Drolez wrote:
I recently had to boot a brand new system using a Marvel Yukon2 NIC
(sk98lin) driver which is not supported by the latest kernel (pci ids =
11ab:4361).
So I compiled the GPLed driver available from Syskonnect,
Hamish Marson wrote:
> I just installed Gentoo distribution on a new PC for a friend who's
> new to Linux, and discovered that although SysKonnect kindly provide
> full source code drivers for their various products on their website,
> that even the latest released kernel sources (i.e. 2.6.12)
Hamish Marson wrote:
I just installed Gentoo distribution on a new PC for a friend who's
new to Linux, and discovered that although SysKonnect kindly provide
full source code drivers for their various products on their website,
that even the latest released kernel sources (i.e. 2.6.12) still
Patrick McHardy wrote:
> We decided to revert the responsible change because it caused problems
> in other areas as well. This patch should fix your problem.
Thanks, it works. If you decide to revisit this in the future, feel free to
send me a patch and I will help test it.
Daniel
-
To
Patrick McHardy wrote:
We decided to revert the responsible change because it caused problems
in other areas as well. This patch should fix your problem.
Thanks, it works. If you decide to revisit this in the future, feel free to
send me a patch and I will help test it.
Daniel
-
To unsubscribe
Neil Darlow wrote:
> Hi Vojtech,
>
> On Friday 08 Jul 2005 22:24, Vojtech Pavlik wrote:
>
>>In the current input GIT tree there is a patch to reverse the order of
>>probing (PnP first) for exactly this reason. I expect 2.6.13 should have
>>the fix.
>
>
> Daniel, is it worth backporting this
Neil Darlow wrote:
Hi Vojtech,
On Friday 08 Jul 2005 22:24, Vojtech Pavlik wrote:
In the current input GIT tree there is a patch to reverse the order of
probing (PnP first) for exactly this reason. I expect 2.6.13 should have
the fix.
Daniel, is it worth backporting this fix for
Patrick McHardy wrote:
> You could confirm this theory by logging invalid packets in LOCAL_OUT
> and in PRE_ROUTING - only PRE_ROUTING should trigger. I'm going to
> think about a solution meanwhile.
You'll have to forgive my lack of netfilter knowledge, I set up my firewall
ages ago and haven't
Hi,
Some Gentoo users have reported very long application startup times in 2.6.12.
This seems to be because the applications are attempting to connect to local
ports such as sunrpc/portmap (where these services are not running), but some
packets are being dropped, so the application load just
Hi,
Some Gentoo users have reported very long application startup times in 2.6.12.
This seems to be because the applications are attempting to connect to local
ports such as sunrpc/portmap (where these services are not running), but some
packets are being dropped, so the application load just
Patrick McHardy wrote:
You could confirm this theory by logging invalid packets in LOCAL_OUT
and in PRE_ROUTING - only PRE_ROUTING should trigger. I'm going to
think about a solution meanwhile.
You'll have to forgive my lack of netfilter knowledge, I set up my firewall
ages ago and haven't
Anton Altaparmakov wrote:
> )-: I have addressed the only things I can think off that could cause
> the oops and below is the resulting patch. Could you please test it?
Yeah!! After removing I_WILL_FREE stuff, that fixed both the oops *and* the
hang. Everything works nicely now.
Thanks a
Anton Altaparmakov wrote:
)-: I have addressed the only things I can think off that could cause
the oops and below is the resulting patch. Could you please test it?
Yeah!! After removing I_WILL_FREE stuff, that fixed both the oops *and* the
hang. Everything works nicely now.
Thanks a
Christian Kujau wrote:
> oh, this sounds good. strange though, that my 2.6.11-gentoo-r5 (whatever
> they've patched in there) *never* oopsed the days ago but all of a sudden
> started to oops yesterday
Probably because you changed alsa-lib versions. By the way, it is fixed in
Christian Kujau wrote:
oh, this sounds good. strange though, that my 2.6.11-gentoo-r5 (whatever
they've patched in there) *never* oopsed the days ago but all of a sudden
started to oops yesterday
Probably because you changed alsa-lib versions. By the way, it is fixed in
David Ford wrote:
> It seems that 2.6.12-rc1 introduced an ALSA bug generating an oops for a
> null pointer.
>
> codec_semaphore: semaphore is not ready [0x1][0x300300]
> codec_read 0: semaphore is not ready for register 0x2c
> Unable to handle kernel NULL pointer dereference at virtual address
>
David Ford wrote:
It seems that 2.6.12-rc1 introduced an ALSA bug generating an oops for a
null pointer.
codec_semaphore: semaphore is not ready [0x1][0x300300]
codec_read 0: semaphore is not ready for register 0x2c
Unable to handle kernel NULL pointer dereference at virtual address
Peter Baumann wrote:
On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
Peter Baumann <[EMAIL PROTECTED]> wrote:
I'm hitting an annoying bug in kernel 2.6.11.5
Every time I _reboot_ (warmstart) my pc my two network cards won't get
recognized any longer.
Following error message appears
Peter Baumann wrote:
On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
Peter Baumann [EMAIL PROTECTED] wrote:
I'm hitting an annoying bug in kernel 2.6.11.5
Every time I _reboot_ (warmstart) my pc my two network cards won't get
recognized any longer.
Following error message appears on
his doesn't work out correctly when a PID has more
than one child task, which is quite often the case.
This should fix it up.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
--- linux-2.6.11-gentoo-r5/fs/proc/base.c.orig 2005-04-02 20:47:10.0 +0100
+++ linux-2.6.11-gentoo-r5/fs/pr
quite often the case.
This should fix it up.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
--- base.c.orig 2005-04-02 20:47:10.0 +0100
+++ base.c 2005-04-02 20:51:43.0 +0100
@@ -1337,6 +1337,8 @@
static struct inode_operations proc_tgid_attr_inode_operations;
#endif
+static
401 - 500 of 540 matches
Mail list logo
