On Tue, 5 Dec 2000, Linus Torvalds wrote:
> Anybody else who has had problems with PCI interrupt routing (tends to be
> "new" devices like CardBus, ACPI, USB etc), can you verify that this
> either fixes things or at least doesn't break a setup that had started
> working earlier..
problems with
On Wed, 6 Dec 2000, Linus Torvalds wrote:
> On Wed, 6 Dec 2000, Martin Diehl wrote:
> >
> [Cardbus config space lost after APM suspend/resume]
>
> Can you remind me in a day or two if I haven't gotten back to you? I don't
> have any machines that need this, but
On Mon, 28 Aug 2000, Linus Torvalds wrote:
> "notify_parent()" uses p->p_pptr without any locking. As far as I can
> tell, that is wrong. It looks like it should have a read-lock on the
> tasklist_lock in order to not be racy (perhaps the parent does an exit on
> another CPU at just this moment
On Sun, 10 Sep 2000, Alan Cox wrote:
> 2.2.18pre4
> o Fix some of the dquot races (Jan Kara)
this appears to be basically the same patch as applied to 2.4.0t8 vs. t7
producing an Oops in dquot_transfer(). This issue can (at least) be
triggered by chown'ing a file on an (
On Tue, 12 Sep 2000, David Ford wrote:
> Please add 'Quota support causes OOPS' Someone posted a patch but I don't
> have the reference offhand. That patch appears to have fixed one person's
> problems.
[..]
>
> > * Oops in dquot_transfer (Dav
On Wed, 20 Sep 2000, J Brook wrote:
> >>EIP; c01527b9<=
> Trace; c015357b
this is the quota issue for which I've posted a fix some days ago.
It's (as of 2.4.0-t9p5) waiting on the TODO list to be merged.
I'd consider it "critical" (wrt what Linus accepts for 2.4.0) as
processes call
On Wed, 20 Sep 100, Sebastian Willing wrote:
It's almost impossible to extract some useful information from your
oops without your kernel symbols (Documentation/oops-tracing.txt).
However, to make a guess, this
> Unable to handle kernel NULL pointer dereference at
virtual address 0034
On Thu, 21 Sep 2000, Rik van Riel wrote:
> I've found and fixed the deadlocks in the new VM. They turned out
> to be single-cpu only bugs, which explains why they didn't crash my
> SMP tesnt box ;)
Hi,
tried
> http://www.surriel.com/patches/2.4.0-t9p2-vmpatch
applied to 2.4.0-t9p4 on UP box b
On Thu, 7 Dec 2000, Linus Torvalds wrote:
> > btw, I'm thinking I could guess the routing from the VLSI config space,
>
> Please do. You might leave them commented out right now, but this is
> actually how most of the pirq router entries have been created: by looking
> at various pirq tables and
On Thu, 7 Dec 2000, Linus Torvalds wrote:
> > btw, I'm thinking I could guess the routing from the VLSI config space,
> > but I don't have any doc's. Would it be worth to try to add some specific
>
> Please do. You might leave them commented out right now, but this is
Ok. Apparently it's the "p
On Thu, 7 Dec 2000, Linus Torvalds wrote:
> Ok, definitely needs some more work. Thanks for testing - I have no
> hardware where this is needed.
Well, so I've tried to go on since my box has this "feature". Seems I
finally got the thing tracked down to several issues with mutual influence
and th
On Fri, 15 Dec 2000, Linus Torvalds wrote:
> I'm surprised: "yenta_init()" will re-initialize the yenta
> PCI_BASE_ADDRESS_0 register, but maybe there's something wrong there. Try
right - but it is just writing back the bogus 0xe6000 thing.
> adding a pci_enable_device() to turn the device on a
On Fri, 15 Dec 2000, Linus Torvalds wrote:
> I suspect that the suspend/resume will do something bad to the BAT
> registers, which control the BIOS area mapping behaviour, and it just
> kills the forwarding of the legacy region to the PCI bus, or something.
FYI: I've identified a single byte in
This is part 2 of the yenta+pm updates for 2.4.0-t12 - to be applied after
part 1. Touching yenta.c only it provides:
- yenta_validate_base() to check and try to fix in case the BIOS has
mapped the cardbus base registers to the legacy area <1M.
IMHO, this would be better placed in the early
Hi,
want to summarize my observations wrt the VM-deadlock issue. Everything
tested on UP box bootet with mem=8M and 500M swap.
2.4.0-t9p4 (vanilla)
deadlocks almost everywhere (even in initscripts!), simple dd with
large enough bs deadlock's as soon as page_out should start - i.e. no
On Mon, 25 Sep 2000, Martin Diehl wrote:
> PS: vmfixes-2.4.0-test9-B2 not yet tested - will do later.
Hi - done now:
using 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 I ended up with the box
deadlocked again! Was "make bzImage" on UP booted with mem=8M.
After about 4 hours at load 2
On Mon, 25 Sep 2000, Marcelo Tosatti wrote:
> There is a known deadlock with Ingo's patch.
>
> I'm attaching a patch which should fix it. (on top of
> vmfixes-2.4.0-test9-B2)
Hi,
Thank You! Seems to be much better now:
Test of 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 + vmfixes-B2-deadlock.patch
On Tue, 26 Sep 2000, Ingo Molnar wrote:
> > Test of 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 + vmfixes-B2-deadlock.patch
>
> note that this is effectively test9-pre7 (with a couple of more fixes and
> the new multiqueue stuff), so you might want to test that as well.
Hi,
have tried the same test
Hi,
On Mon, 2 Oct 2000, Rik van Riel wrote:
> On Sun, 1 Oct 2000, Linus Torvalds wrote:
>
> > - pre8:
> > - quintela: fix the synchronous wait on kmem_cache_shrink().
> > This should fix the mmap02 lockup.
>
> It probably doesn't. People will want to apply my patch
> (on http://www
On Tue, 3 Oct 2000, Rik van Riel wrote:
> On Tue, 3 Oct 2000, Martin Diehl wrote:
>
> > * deadlock in initscripts (even for runlevel 2). SysRq shows idle_task
> > being the only one ever getting the CPU when deadlocked.
>
> This suggests tasks yielding t
On Mon, 11 Sep 2000, Martin Diehl wrote:
> transfer_to[cnt] is initialized to NODQUOT from the first loop
> (due to several continue's e.g.) when entering the second loop.
> Unfortunately I do not feel familiar enough to the quota code to
> provide a patch for this problem.
w
got a reproducible oops with 2.4.0-test8 when trying to login via kdm
as user with restricted quota on local fs - ssh/telnet do not trigger
this issue. 2.4.0-test7 was fine too.
The enclosed trace shows a NULL pointer dereference of an unchecked
struct dquot * passed to check_idq() - called from
On Tue, 3 Oct 2000, Rik van Riel wrote:
> On Tue, 3 Oct 2000, Martin Diehl wrote:
> >
> > Just tried 2.4.0-t9p8 + t9p8-vmpatch: No change here. Box
> > appears to hang upon "init 2" (or higher) when starting several
> > things (sendmail, xfs e.g.) with (acco
Hi,
the following change from t9p7->t9p8 in ide-pci.c
- if ((dev->class & ~(0xfa)) != ((PCI_CLASS_STORAGE_IDE << 8) | 5)) {
+ if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
causes a lot of trouble to me. Seems to be the same thing, which has
already been reported to l-k, but
Hi,
had some long network stalls during initscripts in 2.4.0-test9.
newaliases appeared to block until timeout in do_poll() on udp socket.
I've written a demo program to show what's going on without depending
on initscript and config (DNS/RPC/NIS) issues - attached polltest.c
It sends something t
On Thu, 5 Oct 2000, David S. Miller wrote:
> Fix your /etc/nsswitch.conf to not try to use NIS/NIS+ if you
> do not have these services available.
Yes, of course you are right - incorrect nsswitch.conf will reveal this
problem too - but:
No, the issue I've tried to demonstrate with my polltest.
On Fri, 6 Oct 2000, Andi Kleen wrote:
[icmp errors on unconnected udp sockets not passed to application layer]
>
> Alexey Kuznetsov ([EMAIL PROTECTED]) changed it. Ask him why he did it,
> I agree with you that it would make more sense to keep the old behaviour
> (even though it is differing fr
Hi,
just thinking about the RFC1122 vs. BSD compliance issue wrt error
reporting on unconnected udp sockets i'd like to make a proposal for some
kind of solution:
Synopsis:
Approach to have a default policy whether error reporting on udp
sockets follows the official internet standard from
On Fri, 9 Mar 2001, W. Michael Petullo wrote:
> If you have or have access to a Linux box with a Venus-based modem,
> answering any of these questions would be very helpful:
>
Well, I'm not absolutely sure if we are talking about the same thing: what
I have is a re-labeled PC-Card modem which
On Fri, 9 Mar 2001, Lawrence MacIntyre wrote:
> Uniform MultiPlatform E-IDE driver Revision 6.31
> ide: assuminmg 33 MHz system bus speed for PIO modes: override with
> idebus=xx
> SIS5513: IDE controller on PCI bus 00 dev 09
> PCI: Assigned IRQ 14 for device 00:01.1
> SIS5513: chipset revision 2
On Sun, 11 Mar 2001, Steven Walter wrote:
> > on insmod). This is with SiS5513 rev 208 IDE function from SiS5591
> > chipset with CONFIG_BLK_DEV_SIS5513 and autotune enabled (default).
>
> I have this exact same chip on my board (a PCChips M599-LMR or something
> like that) which works flawless
On Mon, 12 Mar 2001, Steven Walter wrote:
> The big man himself, Andre Hedrick, has stated that the SiS5513 should
> work in UDMA/66 mode, as is evidenced by my setup.
right, but depending on the chipset that provides the SiS5513 function
> SIS5513: chipset revision 208
> SIS5513: not 100% nati
Hi,
for me, vanilla 2.4.3-pre8 refuses to load NIC-modules (8390,ne2k-pci) due
to unresolved symbol: ether_setup
might be related to latest changes at drivers/net/net_init.c
from /proc/ksyms I get:
c024dc8c kbd_ledfunc_Rfa67cc5f
c01ebf8c keyboard_tasklet_R28aa0faa
c024dc84 sysrq_power_off_R0c2
Hi,
Something not so obvious (at least for me ;-) seems to be broken in
userland. Could narrow it down to triggers like failing sed, for example
(from /etc/rc.d/init.d/usb)
PKLVL=`sed 's/^\(.\).*/\1/' < /proc/sys/kernel/printk`
Another probably related thing happens when rc.sysinit sed's from
Hi Linus,
I had some strange userland/proc problems appearing during sysinit.
Symptoms are "Malformed setting kernel.printk=" error message from
sysctl(8) and hanging linuxconf (SAK resolves this). The common thing
are several sed(1) calls silently failing when matching against files
from /proc.
(Linus cc'ed - related thread: 243-pre[78]: mmap changes (breaks) /proc)
On Wed, 28 Mar 2001, Alan Cox wrote:
> 2.4.2-ac27
> o Revert mmap change that broke assumptions (and (Martin Diehl)
> it seems SuS)
the reason to suggest keeping the test was not due to len=
(Linus cc'ed - related thread: 243-pre[78]: mmap changes (breaks) /proc)
On Wed, 28 Mar 2001, Alan Cox wrote:
> 2.4.2-ac27
> o Revert mmap change that broke assumptions (and (Martin Diehl)
> it seems SuS)
the reason to suggest keeping the test was not due to len=
Apparantly this didn't get thru since my mailer was blocked due to
dialup-blacklists (never observed this bevor on l-k!)
so I try to resend it.
Martin
-- Forwarded message --
Date: Mon, 29 Jan 2001 18:22:43 +0100 (CET)
From: Martin Diehl <[EMAIL PROTECTED]>
To:
On Mon, 29 Jan 2001, Linus Torvalds wrote:
> reg = pirq;
> if (reg < 5)
> reg += 0x40;
or adding the 0x41..0x44 cases to the switch statement in my patch?
> > BTW: I was wondering, why we did not update the PCI_INTERRUPT_LINE in
>
> I would prefer _not_ to see this.
>
On Tue, 30 Jan 2001, Robert Siemer wrote:
> > Below is the updated patch. It should handle both (0x01/0x41
> > like) mappings. I can (and did) only test the 0x01 case.
> > USBIRQ routing (0x62) supported, IDE/ACPI/DAQ untouched.
>
> I don't really understand your note above, but your patch alone
On Mon, 29 Jan 2001, Linus Torvalds wrote:
> Now, will the two people in the world who know the pirq black magic now
> stand up and confirm or deride my interpretation?
since I'm certainly not the other one, I'm not going to confirm it ;-)
But, besides it sounds reasonable, I could give some mor
Hi,
while testing the SiS routing code, at some point my ne2k-pci didn't work
anymore. Was when BIOS was set for PnP OS and IRQ set to "auto" for the
NIC. Had to rmmod/insmod the ne2k-pci module after reboot to make it
working again.
Reason: we fetched the irq too early, before calling pci_enab
On Wed, 31 Jan 2001 [EMAIL PROTECTED] wrote:
> I think it would be better to move the pci_enable_device(pdev);
> above all this, as we should enable the device before reading the
> pdev->resource[] too iirc.
Probably I've missed this because the last time I hit such a thing was
when my ob800 bio
(cc's shortened, not to trash Linus et al)
On Thu, 1 Feb 2001, Robert Siemer wrote:
> Is it possible to directly ask the 'IRQ-router' (namely the
> ISA-bridge) for what it is set up for? - I mean which IRQ is routed to
> what without the help of the BIOS?
It's written in the PCI config registe
(apologies in case anybody should get this twice - was catched by the DUL
blocker again. Seems time to change my mail routing anyway...)
On Thu, 1 Feb 2001, Jeff Garzik wrote:
> > Probably I've missed this because the last time I hit such a thing was
> > when my ob800 bios mapped the cardbus me
On Tue, 5 Jun 2001, Pete Wyckoff wrote:
> [EMAIL PROTECTED] said:
> > user-space program is still running. I need to remove the user-space
> > mapping -- otherwise the user process would still have access to the
> > now-freed pages. I need an inverse of remap_page_range().
>
> That seems a bit p
46 matches
Mail list logo
