Hello!
I just tried your 2.4.19-low-latency patch on a stock 2.4.19 kernel and
my box oopses when I manually remove my PCMCIA modem. I know I should
probably use cardctl eject, but I guess the kernel should not oops in
any case and other PCMCIA cards do not have that problem.
I spent the whole day trying to debug the oops because minicom and my
serial console do not seem to want to get along. I suspect a hardware
bug somewhere, I always got garbled output. I managed to capture the
output once but was not able to reproduce the correct settings again, so
apologies if I cannot provide the correct information.
Back to topic: I figured you might be interested in this, so I am
sending you the output of ksymoops. If you need more information I will
be more than happy to provide it.
Thanks for your work on the Linux kernel.
Regards
Diego Biurrun
My system:
Toshiba Satellite 320CDT
Pentium MMX 233 96MB RAM
output of cardctl ident:
Socket 0:
product info: "Kingston", "KNE-CB4TX", "", "1.00"
manfid: 0x0186, 0x0101
function: 6 (network)
Socket 1:
product info: "ROCKWELL", "RFI AnyCom-Eco 336 PC Card", "021", "A"
manfid: 0x0175, 0x0000
function: 2 (serial)
output of lspci -v:
00:00.0 Host bridge: Toshiba America Info Systems 601 (rev a0)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, medium devsel, latency 0
00:04.0 VGA compatible controller: Chips and Technologies F65555 HiQVPro (rev c6) (prog-if 00 [VGA])
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: stepping, medium devsel
Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
Expansion ROM at <unassigned> [disabled] [size=256K]
00:0b.0 USB Controller: NEC Corporation USB (rev 02) (prog-if 10 [OHCI])
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at fcfff000 (32-bit, non-prefetchable) [size=4K]
00:11.0 Communication controller: Toshiba America Info Systems FIR Port (rev 21)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, slow devsel, latency 64, IRQ 11
I/O ports at ffe0 [size=32]
00:13.0 CardBus bridge: Toshiba America Info Systems ToPIC95 (rev 07)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, slow devsel, latency 0, IRQ 11
Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=14, subordinate=14, sec-latency=0
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
16-bit legacy interface ports at 0001
00:13.1 CardBus bridge: Toshiba America Info Systems ToPIC95 (rev 07)
Subsystem: Toshiba America Info Systems: Unknown device 0001
Flags: bus master, slow devsel, latency 0, IRQ 11
Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=15, subordinate=15, sec-latency=0
Memory window 0: 10c00000-10fff000 (prefetchable)
Memory window 1: 11000000-113ff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
16-bit legacy interface ports at 0001
14:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Subsystem: Kingston Technologies: Unknown device 0002
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at 4000 [size=128]
Memory at 10800000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at 10400000 [size=256K]
Diego Biurrun wrote:
>
> Hello!
>
> I just tried your 2.4.19-low-latency patch on a stock 2.4.19 kernel and
> my box oopses when I manually remove my PCMCIA modem.
Yup. The pcmcia drivers like to call sleeping devfs functions
from within a timer handler. The kernel tries to perform a
context switch in interrupt context and bugs out. This can happen
without the low-latency patch, but doesn't.
The fix for that is to change the (strange) deferred deregister thing
in several of the CardServices drivers to punt the activity up to
process context via schedule_task(), but nobody has done that yet.
Probably, you can add
if (in_interrupt())
return;
to schedule() to make the BUGs go away. Not using devfs makes
them go away too - but it is not a devfs bug.
Hi,
I am exporting kernel memory to user processes using mmap() entry point of
my driver. Now, when the user calls unmap(), I would like to deallocate the
pages which I allocated at mmap() time. How can I do that? unmap() entry
point is not provided by vm_operations structure in mm.h file.
I will really appreciate any suggestion/guidance.
Thanks,
Imran.
On Fri, Aug 30, 2002 at 03:53:06PM -0700, Andrew Morton wrote:
> Diego Biurrun wrote:
> >
> > I just tried your 2.4.19-low-latency patch on a stock 2.4.19 kernel and
> > my box oopses when I manually remove my PCMCIA modem.
>
> Yup. The pcmcia drivers like to call sleeping devfs functions
> from within a timer handler. The kernel tries to perform a
> context switch in interrupt context and bugs out. This can happen
> without the low-latency patch, but doesn't.
>
> The fix for that is to change the (strange) deferred deregister thing
> in several of the CardServices drivers to punt the activity up to
> process context via schedule_task(), but nobody has done that yet.
>
> Probably, you can add
>
> if (in_interrupt())
> return;
>
> to schedule() to make the BUGs go away. Not using devfs makes
> them go away too - but it is not a devfs bug.
Thanks for the ultraquick reply. I managed to get another oops trace
from within (shudder) Windows Hyperterminal, I am sending this along
just in case it may help you. Adding the two lines you mention to
sched.c also fixed the problem.
Thank you!
Diego Biurrun
Hi,
Does __get_free_pages(..) return physically contiguous pages?
Thanks,
Imran.
On Tue, 2002-09-03 at 22:19, Imran Badr wrote:
> Does __get_free_pages(..) return physically contiguous pages?
Yes.
Robert Love
On 3 Sep 2002, Robert Love wrote:
> On Tue, 2002-09-03 at 22:19, Imran Badr wrote:
>
> > Does __get_free_pages(..) return physically contiguous pages?
>
> Yes.
But only if they're available. Linux doesn't currently have
any mechanisms for smart defragmentation of physical memory
and even if we had them they couldn't be fully reliable.
So be careful what you ask for, if you ask for too large a
chunk of memory you might end up not getting any at all.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/