Re: quiet kernel parameter

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



On Thu, Jul 28, 2011 at 11:12 AM, Meyithi <mail@xxxxxxxxxxx> wrote:
> On 28 July 2011 16:55, Tom Gundersen <teg@xxxxxxx> wrote:
>
>> Hi Jason,
>>
>> On Thu, Jul 28, 2011 at 5:16 PM, Meyithi <mail@xxxxxxxxxxx> wrote:
>> > Does anybody know the difference between the quiet kernel parameter and
>> > loglevel=4 parameter?
>> >
>> > All of the info I can find states that they should be identical, and
>> > /proc/sys/kernel/printk is identical.
>>
>> They should be identical. Just look at the code:
>> <
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=init/main.c;h=d7211faed2adfb295caf46bbb9c70835f622eabe;hb=HEAD#l201
>> >.
>> The quiet parameter just sets loglevel=4. Unless I'm missing
>> something.
>>
>> > I am however getting framebuffer
>> > corruption during boot when using quiet which doesn't occur when using
>> > loglevel=4.
>>
>> This is very odd. Any more info on this? Screenshots? Can you see a
>> difference in dmesg?
>>
>> Cheers,
>>
>> Tom
>>
>
> Apologies for the format of this post, was supposed to be a draft until I
> gathered a bit more info, but I accidentally sent the first message and was
> hastened.
>
> Anyway, there is a few things I'm looking into, firstly I'm using
> kernel26-ck with syslinux, and I also have intel_agp and i915 in
> mkinitcpio.conf for an earlier framebuffer.  Using quiet seems to switch (or
> attempt to switch) to framebuffer earlier, my entire screen will go grey,
> then switch to black with a white box in the top left which looks to be
> 640x480 and then the boot messages will overwrite the white box and the
> system will commence to boot.  Using loglevel=4, this does not occur.  So
> there must be some difference somewhere, and although it's just initial
> framebuffer corruption it's fired up my curiosity.
>
> I've got a lot to try in order to pin this down, was just hoping somebody
> knew of any differences between quiet and loglevel=4 to save the fiddling.

ah nice, i asked about this *exact* same thing back in May:

http://mailman.archlinux.org/pipermail/arch-general/2011-May/020186.html

... unfortunately no one had an answer, and most said it wasn't
happening to them, but you seem to have narrowed it down more maybe
... it happened on nvidia/ati/intel cards for me -- every single one
of my systems in fact.

i ended up just making a small mkinitcpio hook that ran first and
cleared the buffer ... still a super brief period of corruption, but
looked much better.  the issue i had is identical to what you've
described; interested to see what you find out.

-- 

C Anthony


[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux