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@lists.xensource.com
http://lists.xensource.com/xen-users