>>> On 28.06.13 at 22:58, ar16 <[email protected]> wrote: > As I've been working on figuring out serial console setup for Xen, I now > notice an OOPS on boot > > [ 34.971630] ------------[ cut here ]------------ > [ 34.971639] WARNING: at > /home/abuild/rpmbuild/BUILD/kernel-xen-3.7.10/linux-3.7/drivers/tty/tty_io.c:14 > 30 > tty_init_dev+0x19a/0x1d0() > [ 34.971640] Hardware name: System Product Name > [ 34.971642] tty_init_dev: tty driver does not set tty->port. This > will crash the kernel later. Fix the driver! > [ 34.971643] Modules linked in: xen_scsibk blkbk domctl > blkback_pagemap netbk xenbus_be gntdev evtchn binfmt_misc > snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss > snd_pcm snd_seq snd_timer snd_seq_device snd_mixer_oss snd sr_mod radeon > ttm drm_kms_helper soundcore drm ppdev ata_generic i2c_algo_bit > serio_raw k10temp snd_page_alloc pata_atiixp sp5100_tco i2c_piix4 > i2c_core shpchp sg r8169 sky2 pci_hotplug parport_pc parport floppy > 8250_core asus_atk0110 button n_hdlc slhc nfsd auth_rpcgss nfs_acl nfs > fscache lockd sunrpc autofs4 hid_generic usbhid hid linear ohci_hcd > ehci_hcd usbcore usb_common scsi_dh_alua scsi_dh_rdac scsi_dh_hp_sw > scsi_dh_emc scsi_dh xenblk cdrom xennet sata_sil24 serial_core cpuid edd > fan thermal processor thermal_sys hwmon dummy sha512_generic > sha256_generic sha1_generic ablk_helper cryptd lrw aes_x86_64 xts > gf128mul xfs btrfs zlib_deflate libcrc32c dm_snapshot dm_crypt dm_mod > raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy > async_tx raid10 raid1 raid0 > [ 34.971684] Pid: 1057, comm: rs:main Q:Reg Not tainted > 3.7.10-1.16-xen #1 > [ 34.971685] Call Trace: > [ 34.971697] [<ffffffff80008ae5>] dump_trace+0x85/0x1c0 > [ 34.971702] [<ffffffff804f8449>] dump_stack+0x69/0x6f > [ 34.971707] [<ffffffff8002edc9>] warn_slowpath_common+0x79/0xc0 > [ 34.971711] [<ffffffff8002eec5>] warn_slowpath_fmt+0x45/0x50 > [ 34.971714] [<ffffffff8031f38a>] tty_init_dev+0x19a/0x1d0 > [ 34.971719] [<ffffffff8031fca8>] tty_open+0x318/0x580 > [ 34.971723] [<ffffffff801376df>] chrdev_open+0xbf/0x1e0 > [ 34.971727] [<ffffffff80131526>] do_dentry_open+0x206/0x290 > [ 34.971731] [<ffffffff80140391>] do_last+0x2e1/0xed0 > [ 34.971735] [<ffffffff80141f03>] path_openat+0xc3/0x4f0 > [ 34.971738] [<ffffffff80142cf4>] do_filp_open+0x44/0xb0 > [ 34.971741] [<ffffffff801326e3>] do_sys_open+0xf3/0x1e0 > [ 34.971744] [<ffffffff8050ad0b>] system_call_fastpath+0x1a/0x1f > [ 34.971751] [<00007f4d6b6f2b0d>] 0x7f4d6b6f2b0c > [ 34.971753] ---[ end trace ca20eeab42859431 ]--- > [ 34.971761] Warning: dev (tty10) tty->count(0) != #fd's(1) in tty_open
As the changes to drivers/xen/console/console.c show that patches.xen/xen3-patch-3.7 does, the Xen console driver has been modified to deal with that situation (as obviously I had seen those warnings too earlier on). However, posting just the fragment above makes this all guesswork anyway, as it remains unclear what "console=" and "xencons=" options you may have on your kernel command line. > I'm NOT sure if this is related to some `shutdown` issues I'm having; > trying to figure out what's related, and what's not. > > Jan, I'm cc'ing you just to 1st ask -- does this ^^^ discussion/oops > belong here in -virtual, or over on the -kernel side? I very much doubt that kernel side console handling issues matter with reboot, which is done entirely in the hypervisor (even more so that you get a message from the hypervisor stating that it at least started the reboot sequence, i.e. control wouldn't return to the Dom0 kernel after that point). Jan -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
