kernel26-one-dev 2.6.30rc5-1

  • New acerhdf patch and it defaults to kernel mode now. No need for rc.local tricks anymore.
  • ACPI video and some LCD backlight code compiled in statically due a kernel bug.
  • ACPI powersave, userspace and conservative built as modules. Defaults to ondemand governor.
  • cpufreq_stats added as module. pciehp, acpiphp compiled statically.
  • NTFS read/write support is now available as a module.
  • Removed CONFIG_LATENCYTOP, CONFIG_FRAME_POINTER and CONFIG_SYSCTL_SYSCALL_CHECK.
  • Removed Hardware crypto devices support completely.
  • Removed debugging code to make kernel slightly faster, but unfortunately this means a dropped support for the LatencyTOP tool.
  • Dropped support completely for the wifi led patches as they don’t apply to the 2.6.30 kernel tree anymore.
  • Added a patch which tweaks the deadline scheduler’s fifo_batch from 16 to 1 for slightly better SSD responsiviness.
  • Added support for the KMS.
  • Kernel’s boot time has increased from 3.7 seconds to 4.8 seconds on my system. Probably due the fact that more static code has been compiled into the kernel than on previous releases. Init seems to be working faster though(??).
  • Your mileage may vary depending on the external peripherals and filesystems used.
  • The time to suspend the laptop has decreased (tested with s2ram). It’s almost immediate now.

2 cose:

  1. commentate in rc.local:
  2. echo kernel > /sys/class/thermal/thermal_zone0/mode
    inoltre non vengono più usate le chiavi kernel e user perchè sono state sostituite da enable e disable

  3. nel mio caso ho dovuto riconfigurare e risistemare l’xorg con Xorg -configure, credo che il problema riguardasse l’opzione per l’accelerazione della scheda (EXA,UXA ecc)

kernel26-one-dev-2.6.29-2

New featuress are:
- acerhdf has been integrated to the kernel. The package conflicts now with ‘acerfand’ and ‘acerhdf’.
- MTRR issues fixed
- Strange Xorg memory errors fixed (compiled without PAT)

link

Non serve più quindi lanciare il demone acerfand, perchè la ventolina viene gestita dal modulo acerhdf ideato da Peter Feuerer.

Per vedere se funziona possiamo dare un:

[~] dmesg | grep acerhdf
[ 1.313520] acerhdf: version: 0.4.0 compiledate: Mar 26 2009 15:47:14
[ 1.313524] acerhdf: biosvendor:Acer
[ 1.313528] acerhdf: biosversion:v0.3309
[ 1.313531] acerhdf: biosrelease:10/06/2008
[ 1.313535] acerhdf: biosproduct:AOA150
[~]

mentre per la temperatura:

[~] cat /sys/class/thermal/thermal_zone0/temp
61

Per altre informazioni, settaggi ecc trovate spiegato tutto nel readme del pacchetto.

Per farlo funzionare ho dovuto cambiare l’operation mode da user a kernel mode:

# echo kernel > /sys/class/thermal/thermal_zone0/mode

perchè di default stranamente parte in modalità user, mentre nel readme c’è scritto che la modalità di default è quella kernel… per il momento basta mettere ad esempio quella riga nell’rc.local.

error during nfq_unbind_pf()


[~] tail /var/log/moblock.log
.....
.....
error during nfq_unbind_pf()
Error during nfq_bind_pf()

Il problema è la mancanza del driver nfnetlink_queue, e si verifica facendo partire moblock sul kernel kernel26-one-dev (precisamente la versione che uso è la 2.6.29rc1git5-1).
L’unica soluzione è ricompilare il kernel abilitando il parametro “CONFIG_NETFILTER_NETLINK_QUEUE”, un modo veloce per farlo è aprire direttamente il .config e sostituire:

# CONFIG_NETFILTER_NETLINK_QUEUE is not set

con:

CONFIG_NETFILTER_NETLINK_QUEUE=m

Al riavvio verranno automaticamente caricati i moduli necessari.

kernel 2.6.29-rc3-fastboot e nvidia on AMD64

Ho appena provato questo kernel sul pc a 64 bit per vedere al lavoro la nuova versione 1.0-1 di sreadahead con il filesystem ext4.

L’installazione del kernel non ha dato problemi, anche importando il “vecchio” .config che avevo bello e pronto dal 2.6.28 (cambiando ovviamente il tipo di filesystem, da ext3 a ext4). Cosa diversa invece per l’installazione dei driver nvidia, che comunque sono riuscito a installare grazie al suggerimento fornito da Berseker nella discussione ufficiale del forum.

Quindi per chi possiede una scheda nvidia e vuole provare quel kernel, i passi da seguire a grandi linee sono questi:

[~] cat /boot/grub/menu.lst

….

title  Arch Linux fastboot
root   (hd0,4)
kernel /boot/vmlinuz26-fastboot root=/dev/sda5 ro quiet

title  Arch Linux fastboot with checkdisk
root   (hd0,4)
kernel /boot/vmlinuz26-fastboot root=/dev/sda5 ro quiet checkdisk

title  Arch Linux fastboot with Bootchart
root   (hd0,4)
kernel /boot/vmlinuz26-fastboot root=/dev/sda5 ro quiet  init=/sbin/bootchartd

  • si scaricano gli ultimi driver nvidia dal sito nvidia;
  • si riavvia e si entra nel nuovo kernel in modalità init 3;
  • si controlla di avere i sorgenti del nuovo kernel nella directory /usr/src/linux-2.6.29-rc3-fastboot/ (nel mio caso mancava quel “rc3″ e ho dovuto rinominarla);
  • si installano i driver nvidia, e se avete seguito per bene i passaggi sopra, l’installazione dovrebbe andare a buon fine;
  • si installa il pacchetto sreadahead da aur, seguendo le istruzioni presenti sul forum;
  • e per finire si misurano i tempi di boot con bootchart.

Questo è il mio (penoso):

bootchart.png

2 array MODULES per 2 kernel

Nell’articolo precedente vi ho raccontato che ho dovuto usare il kernel ufficiale invece del dev, così ho dovuto editare l’rc.conf sistemando l’array modules. Ma in questo modo per bootare nel kernel dev dovevo ricordarmi di rieditare quel file, risistemando nuovamente l’array.
Da qui l’idea di automatizzare il tutto: per prima cosa modifichiamo l’rc.conf in modo da avere qualcosa di simile a questo:

[~] cat /etc/rc.conf
#
# /etc/rc.conf - Main Configuration for Arch Linux
#
.....
.....
MOD_AUTOLOAD="no"
.....
# moduli usati dal kernel arch ufficiale
MODULES=(!snd_pcsp !pciehp ath5k scsi_mod .......... )
# moduli per un altro kernel
MODULES_II=(uhci_hcd) #(mouse)
.....
.....

poi editiamo /etc/rc.sysinit, modificando la parte relativa al caricamento dei moduli in questa maniera:

[~] cat /etc/rc.sysinit
#!/bin/bash
#
# /etc/rc.sysinit
#
.....
.....

MODULES_default=`/bin/sed "s/.*-ARCH.*/-ARCH/" /proc/version`
if [ "$MODULES_default" = "-ARCH" ]; then

# default, parte solita di caricamento dei moduli:

    if ! [ "$load_modules" = "off" ]; then
        if [ -f /proc/modules ]; then
    #        stat_busy "Loading Modules"
            for mod in "${MODULES[@]}"; do
                if [ "$mod" = "${mod#!}" ]; then
                    /sbin/modprobe $mod
                fi
            done
    #        stat_done
        fi
        if [ -d /proc/acpi ]; then
      ACPI_MODULES="ac battery button fan processor thermal"
      k="$(echo $BLACKLIST ${MOD_BLACKLIST[@]} | /bin/sed 's|-|_|g')"
      j="$(echo ${MODULES[@]} | /bin/sed 's|-|_|g')"
      #add disabled MODULES (!) to blacklist - much requested feature
       for m in ${j}; do
                  [ "$m" != "${m#!}" ] && k="${k} ${m#!}"
      done
            # add disablemodules= from commandline to blacklist
k="${k} $(echo ${disablemodules} | /bin/sed 's|-|_|g' | /bin/sed 's|,| |g')"
            for n in ${ACPI_MODULES}; do
                if ! echo ${k} | /bin/grep "\<$n\>" 2>&1 >/dev/null; then
                    /sbin/modprobe $n > /dev/null 2>&1
                fi
            done
        fi
    fi

#parte aggiunta:    
else

    #caricamento dei moduli nell'array aggiunto in rc.conf MODULES_II

        if [ -f /proc/modules ]; then
            for mod in "${MODULES_II[@]}"; do
                if [ "$mod" = "${mod#!}" ]; then
                    /sbin/modprobe $mod
                fi
            done
      fi

fi


 .....
 .....
 

(non so come vedete il codice sopra sul vostro monitor, con la mia risoluzione lo vedo tagliato e quindi ve l’ho messo anche qui).

Ovviamente queste sono modifiche che vanno bene nel mio caso, ma se ad esempio usate un secondo kernel modulare e non specificate nel nuovo array i moduli per gestire l’acpi, vi conviene tenere la parte di caricamento anche per quei moduli.

E infine come avrete già visto la modifica funzionerà finchè il kernel ufficiale sarà del tipo:

[~] uname -r
2.6.28-ARCH
[~]

moduli aspire one

Per attivare moblock ho dovuto temporaneamente bootare sul kernel ufficiale, così ho sistemato anche l’array dei moduli, questi sono quelli che uso:

/etc/rc.conf :

...
MOD_AUTOLOAD="no"
...
MODULES=(!snd_pcsp !pciehp ath5k scsi_mod libata pata_acpi ata_generic acpi_cpufreq ata_piix sd_mod mbcache ext4 rtc_lib rtc_core rtc_cmos mii ac battery button fan processor thermal evdev wmi led_class rfkill acer_wmi mii agpgart r8169 intel_agp usbcore iTCO_vendor_support iTCO_wdt soundcore snd snd_hwdep snd_page_alloc snd_timer sg ehci_hcd i2c_core uhci_hcd i2c_i801 snd_pcm snd-hda-intel serio_raw output psmouse video v4l1_compat videodev compat_ioctl32 uvcvideo snd_seq_midi_event snd_seq_oss hid usbhid joydev hso drm i915 intel-agp usb-storage)

Però così non funziona lo scroll del touchpad, sto cercando di capirne il motivo perchè bootando su qualsiasi altro kernel o abilitando l’autoload dei moduli funziona.

Couldn’t mount because unsupported optional features (40)

Questo messaggio:

\dev\sdaX Couldn’t mount because unsupported optional features (40)”

mi è apparso cambiando la root in ext4 (vedi articolo precedente). Non blocca l’avvio del sistema e le partizioni vengono comunque montate, ma visto che non è il massimo da vedere ho cercato su google e in pratica ho capito che viene visualizzato quando il kernel cerca prima di montare la partizione usando il driver per ext3, qui compare quel messaggio, e poi la monta correttamente usando i driver appunto per ext4.

Ho quindi ricompilato il kernel (uso sempre quello dev) settando l’ext4 come statico e togliendo il resto (ext2,3,reiserfs,jfs ecc ecc tranne vfat) ma al riavvio è comparso questo errore di grub:

invalid or unsupported executable format

risolto con (avviando da un altro kernel o usando sysrescuecd):

grub-install --recheck /dev/sda

come riportato sulla ArchWiki. (l’avessi letta prima evitavo di ricompilarmi il kernel 3 volte..)