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

Re: Pre-bug-raising questions



On Mon, Jan 19, 2009 at 4:57 PM, Ian Campbell <ijc@hellion.org.uk> wrote:
> On Mon, 2009-01-19 at 16:43 +0000, Mike Grice wrote:
>> 2009/1/19 Mike Grice <mgrice@plus.net>:
>> > On Mon, Jan 19, 2009 at 4:10 PM, Ian Campbell <ijc@hellion.org.uk> wrote:
>> >> On Mon, 2009-01-19 at 14:12 +0000, Mike Grice wrote:
>> >>>
>> >>> Select a language: English
>> >>> Choose Language: default
>> >>> Detect Network Hardware:
>> >>> "No Ethernet card was detected. If you know the name of the driver
>> >>> │
>> >>>   │ needed by your Ethernet card, you can select it from the list."
>> >>
>> >> Do you have something akin to /sys/bus/sunv/devices/blah? With modalias
>> >> entries here and in the module the installer should be able to make the
>> >> connection between one and the other. For example for Xen virtual
>> >> devices we have:
>> >>        di32:~# cat /sys/bus/xen/devices/vif-0/modalias
>> >>        xen:vif
>> >>        di32:~# modinfo xen-netfront
>> >>        filename:       /lib/modules/2.6.26-1-686-bigmem/kernel/drivers/net/xen-netfront.ko
>> >>        alias:          xennet
>> >>        alias:          xen:vif
>> >>        license:        GPL
>> >>        description:    Xen virtual network device frontend
>> >>        depends:
>> >>        vermagic:       2.6.26-1-686-bigmem SMP mod_unload modversions
>> >>        686
>> >>
>> >> So the xen:vif modalias ties into the alias on the module.
>> >
>> > Ok, that's pretty interesting.  I suspect that the console support is
>> > compiled into the kernel via the CONFIG_LDOMS kernel option though
>> > (the net and disk are modules).  The giveaway for that would be the
>> > very sparse loaded module list:
>> >
>> > hostname:~# lsmod
>> > Module                  Size  Used by
>> > ipv6                  307168  72
>> > ext3                  142672  2
>> > jbd                    50856  1 ext3
>> > sunvnet                16132  0
>> > sunvdc                 12168  5
>> >
>> > Theres some interesting things in dmesg about console shenanigans:
>> > hostname:~# dmesg | grep -E '(cons|tty|prom)'
>> > [    0.000000] console [earlyprom0] enabled
>> > [    0.000000] OF stdout device is: /virtual-devices@100/console@1
>> > [22750.854590] console handover: boot [earlyprom0] -> real [tty0]
>> > [22755.397980] f02795dc: ttyS0 at I/O 0x0 (irq = 17) is a SUN4V HCONS
>> > [22755.400034] console [ttyHV0] enabled
>> >
>> > The console I'm having problems with is the virtual one where it
>> > simulates being 'at the console'.  From the primary LDOM (domain 0 in
>> > xenspeak), you telnet to localhost on a port and it dumps you to that
>> > console.
>> >
>> > The weird thing is that this console works completely fine during the
>> > debian-installer (even with colour and tabbing, etc.) but once you
>> > reboot into the new Debian install, the console is effectively
>> > 'read-only' (I see the login: prompt, but no matter what key
>> > combination I press, my typing does not show at the other side).
>> >
>> > The output of dmesg and a find in /sys are attached if you think
>> > perusing these will help...
>>
>> Ok, to answer my own question, this console seems to have become a
>> serial console after the reboot.  Just on a hunch I edited
>> /etc/inittab (via my ssh connection), uncommented the ttyS0 line (the
>> one you normally use to enable the serial console) and after an 'init
>> q' my virtual console that was open in another window sprang into life
>> with a normal banner.
>>
>> How you'd take care of that in the installer in a nice way, I have no idea...
>
> For Xen I had to add code to
> packages/finish-install/finish-install.d/90console to make this work.
> It's r54359 in the Debian installer SVN repo
> http://svn.debian.org/viewsvn/d-i?rev=54359&view=rev
>
> If your device is hvc0 as well then adding an || to that if statement
> seems reasonable.

Hi Ian,

Having found that it's the weird behaviour of LDOM changing the device
from one type to another, I think its fair to say its down to the
person doing the installing to make sure this is picked up properly,
it's just inconvenient rather than broken.  Although for a non-network
install you will have problems, so yeah, that kind of workaround is a
good idea, thanks.

The main concern I have is the autodetection of the hardware... I
don't know how the installer works enough to see what bit isn't
working there, so I'll have to do some digging :-(

Mike


Reply to: