Re: [Xen-users] 3.0.0: tg3 & sata_sil crashes

[Molle Bestefich <molle.bestefich@xxxxxxxxx>]

Ian Pratt wrote:
> > I get the following in dmesg when booting dom0 under xen-3.0.0.
> > If someone could explain why I'd very much appreciate it :-).
> >
> > 1.)
> > Looks bad enough, but the SATA disks are usable, so
> > apparently not critical:
> >
> > kobject_register failed for sata_sil (-17)
> >
> > Call Trace:
> > <ffffffff801ef976>{kobject_register+70}
> > <ffffffff80243dab>{bus_add_driver+107}
> > <ffffffff801fc063>{pci_register_driver+131}
> > <ffffffff80151915>{sys_init_module+325}
> > <ffffffff80112406>{system_call+134}
> > <ffffffff80112380>{system_call+0}
>
> I saw something similar to this when using a bleeding edge compiler a
> while back.
>
> Are you building your own xen/kernel?

Yes.  Thought I was supposed to :-).

> What compiler?

I'm in unfamiliar territory here so this is probably too much info.
Hope the right stuff is here too:

/etc/make.conf:
  CFLAGS="-march=opteron -O2 -mno-tls-direct-seg-refs -pipe"
  CHOST="x86_64-pc-linux-gnu"
  CXXFLAGS="${CFLAGS}"
  MAKEOPTS="-j2"
  USE="nptl nptlonly"

gcc -v:
  Reading specs from /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/specs
  Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure
    --prefix=/usr   --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.4.4
    --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include
    --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4
    --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/man
    --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.4.4/info
    --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/include/g++-v3
    --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu
--disable-altivec --enable-nls
    --without-included-gettext --with-system-zlib --disable-checking
--disable-werror
    --disable-libunwind-exceptions --enable-multilib --disable-libgcj
    --enable-languages=c,c++,f77 --enable-shared --enable-threads=posix
    --enable-__cxa_atexit --enable-clocale=gnu
  Thread model: posix
  gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8)

ld -v:
  GNU ld version 2.16.1

> Have you modified the config?

Only slightly.
I found out over a couple of iterations that if I made more than
absolutely minimal changes to the config, the kernel build would fail.
 So I've actually just enabled built-in kernel support for my ATA
controller, nothing else AFAIR.

(I was even so annoyed that I was thinking of doing an automated test
suite to run through all permutations of xen/kernel configurations,
figure out which options cause failures and post results to this list
once a week, but that'll have to wait till I get basic things working
and some free time shows up in the horizon. :-))

>
> > 2.)
> > Not sure why tg3 is mentioned below - when I cat
> > /proc/interrupts, only ohci_hcd seems to be using irq 19.  In
> > fact, tg3 (tigon3) doesn't seem to have any interrupts
> > assigned, but then again the network adapter seems to be
> > working fine anyway.
>
> It certainly wouldn't be working if it didn't have an interrupt
> assigned. If its not listed in /proc/interrupts then something is deeply
> confused on your system.

Hmm, I might have been confused.  I was looking for tg3.  This could be it:
[/proc/interrupts snippet:]
 31:       1368        Phys-irq  peth0

> Getting spurious interrupts isn't that uncommon on some motherboards.

Ok.  It just sounded sort of unhealthy to me..

> > irq 19: nobody cared!
> >
> > Call Trace:
> > <ffffffff80155250>{__report_bad_irq+48}
> > <ffffffff80155329>{note_interrupt+89}
> > <ffffffff80154b5c>{__do_IRQ+252}
> > <ffffffff80115f04>{do_IRQ+52}
> > <ffffffff8010db65>{evtchn_do_upcall+197}
> > <ffffffff880349b0>{:bridge:br_handle_frame_finish+0}
> > <ffffffff80112cf1>{do_hypervisor_callback+17}
> > <ffffffff8010da2c>{force_evtchn_callback+12}
> > <ffffffff8010da2c>{force_evtchn_callback+12}
> > <ffffffff8800cfe1>{:tg3:tg3_interrupt_tagged+417}
> > <ffffffff80154a0c>{handle_IRQ_event+76}
> > <ffffffff80154b3c>{__do_IRQ+220}
> > <ffffffff80115f04>{do_IRQ+52}
> > <ffffffff8011a5fe>{monotonic_clock+78}
> > <ffffffff8010db65>{evtchn_do_upcall+197}<ffffffff80112cf1>{do_
> > hypervisor_callback+17}
> > <ffffffff8011035a>{xen_idle+106}
> > <ffffffff8011035a>{xen_idle+106}
> > <ffffffff801103aa>{cpu_idle+58}
> > <ffffffff804c871a>{start_kernel+490}
> > <ffffffff804c819a>{_sinittext+410}
> >
> > handlers:
> > [<ffffffff802a80e0>] (usb_hcd_irq+0x0/0x70)
> > [<ffffffff802a80e0>] (usb_hcd_irq+0x0/0x70)
> >
> > Disabling IRQ #19
> >
> >
> > Hope that someone can bring me up to date.
> >
> > Btw, out of curiosity, I'm wondering what the "+100" etc.
> > numbers above mean.
> > Is it a byte offset into my particular compilation of the source code?
> > If that's the case, is that actually useful to anyone?
>
> Yes and yes. It can give you an idea of how far into the function the
> call is.

Cool, thanks for clearing that up.
("idea of" - the imprecision of that piece of technology makes me shudder :-).)

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users