bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Mach: disabling all network device drivers


From: Diego Nieto Cid
Subject: Re: GNU Mach: disabling all network device drivers
Date: Wed, 8 Dec 2010 02:52:10 -0300

Hello,

2010/8/30 Diego Nieto Cid <dnietoc@gmail.com>
>
> Short story: something is clearing kernel_page_dir.
>

Here's some information about this issue.

After modifing qemu to generate an instruction trace and stop when a physical
memory location is modified, I've found that interrupts are being nested too
deeply. Thus the stack used by their handlers starts to grow until it oveflows
and other variables are overwritten.

When this happens, the first variable before _intstack (it grows from bottom to
top) is destroyed and it eventually reaches kernel_page_dir which is
the variable
I was watching.

gnumach symbols:

  00188828 B net_kmsg_size
  0018882c B active_stacks
  00188830 B kernel_page_dir
  00188840 B ipc_notify_msg_accepted_template
  00188860 B virtual_space_end
  00188880 B proc_net_inode_operations
  001888d0 B _intstack
  001898d0 B sched_thread_id

Intruction (back)trace:

  0xc010665a - 0xc010664d * gnumach-uld-HEAD/i386/i386/spl.S:214-212
  0xc0106646              * gnumach-uld-HEAD/i386/i386/spl.S:210
  0xc0134bba - 0xc0134bb1 * gnumach-uld-HEAD/i386/i386at/interrupt.S:39-37
  0xc0134baf - 0xc0134ba4 * gnumach-uld-HEAD/i386/i386at/interrupt.S:35-30
  0xc01054cc              * gnumach-uld-HEAD/i386/i386/locore.S:707
  0xc0105486 - 0xc010547f * gnumach-uld-HEAD/i386/i386/locore.S:648-647
  0xc010547e - 0xc010547c * gnumach-uld-HEAD/i386/i386/locore.S:645-643
  0xc0105446 - 0xc0105440 * gnumach-uld-HEAD/i386/i386/locore.S:630

  0xc0106668 - 0xc010664d * gnumach-uld-HEAD/i386/i386/spl.S:216-212
  0xc0106646              * gnumach-uld-HEAD/i386/i386/spl.S:210
  0xc0134bba - 0xc0134bb1 * gnumach-uld-HEAD/i386/i386at/interrupt.S:39-37
  0xc0134bad - 0xc0134ba4 * gnumach-uld-HEAD/i386/i386at/interrupt.S:34-30
  0xc01054cc              * gnumach-uld-HEAD/i386/i386/locore.S:707
  0xc0105486 - 0xc010547f * gnumach-uld-HEAD/i386/i386/locore.S:648-647
  0xc010547e - 0xc010547c * gnumach-uld-HEAD/i386/i386/locore.S:645-643
  0xc0105416 - 0xc0105410 * gnumach-uld-HEAD/i386/i386/locore.S:626


(* means I assumed these addresses were owned by the kernel and substracted
0xc0000000 before giving them to addr2line.)

It goes on alternating these two blocks. The first is the handler for
interrupt 11 (assigned to the ethernet card) and the second is interrupt
7.

Next, dde_pcnet32 appears:

  0x804b4cd       ??:0    ( dde_pcnet32::outw_local )
  ...
  0x804b527       ??:0   ( dde_pcnet32::outw )
  ...
  0x804b4cd       ??:0    ( dde_pcnet32::outw_local )
  ...
  0x804b507       ??:0   ( dde_pcnet32::outw )
  ...
  0x804bf83       ??:0  ( dde_pcnet32::pcnet32_wio_write_csr )
  ...
  0x804fb68       ??:0 ( dde_pcnet32::pcnet32_open )

pcnet32_wio_write_csr call is located at the following line:

  dde_pcnet32/pcnet32.c:2298 lp->a.write_csr(ioaddr, CSR0, CSR0_NORMAL);

Writting CSR0_NORMAL to pcnet's CSR0 register sets the 'interruption enabled'
bit allowing the hardware to raise interruptions.

So, why would such an amount of interruptions be triggered?
Their alternating pattern is also interesting. What's interrupt 7 and
how is it related to 11?

The full trace, memory dumps and qemu's patch may be downloaded from:
( 12M, but it expands to around 495M )

http://web.fi.uba.ar/~mnieto/_borrar/archhurd/nested_interrupts.tar.xz



reply via email to

[Prev in Thread] Current Thread [Next in Thread]