kernel muckt rum

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
Benutzeravatar
Harakiri
Beiträge: 250
Registriert: 31.10.2009 18:00:47
Lizenz eigener Beiträge: MIT Lizenz

kernel muckt rum

Beitrag von Harakiri » 25.01.2010 22:22:48

hallo,
ich habe bei mir sidux 64bit am laufen. das ganze funktioniert auch soweit, allerdings bekomme ich nach einer weile immer fehlermeldungen, die offensichtlich am sidux-kernel liegen. denn mein zugriff auf die zweite festplatte funktioniert dann nicht mehr und ich bekomme eine fehlermeldung.

als erstes habe ich dieses problem natürlich im sidux-forum angesprochen, aber wirklich helfen konnte mir dort niemand. letztlich blieb mir dort als empfehlung, dass ich meine zweite ide-festplatte ausstöpsel und nur noch auf meine größere sata-festplatte arbeiten solle, wegen mischbetrieb (probleme usw.).

aber: dieses problem habe ich ausschließlich mit allen sidux-kerneln, alle anderen kernel (ubuntu, debian etc) funktionieren reibungslos. meine vorläufige lösung ohne den ausbau meiner ide-festplatte ist daher, den debian standard-kernel 2.6.32-trunk-amd64 mit sidux zu benutzen, denn das funktioniert.

meine frage lautet daher, ob vielleicht jemand von euch weiß, welche einstellung im sidux-kernel dafür verantwortlich sein könnte, dass diese probleme auftreten? ansonsten belasse ich es einfach dabei wie es jetzt ist.

anbei füge ich mal auszüge der beschreibung des problems, um die details zu veranschaulich:
... leider habe ich sporadisch auftretende fehlermeldungen des kernels (2.6.31-6.slh.1-sidux-amd64 als auch 2.6.32-4.slh.2-sidux-amd64). er meldet mir zugriffsprobleme auf meine zweite hdd (sdb) mit ext4. die meldung lautet "mpage_da_map blocks block allocation for inode .... with error -30)" oder auch "ata5.00 exception emask frozen ... status drdyerr ... revalidation failed ... buffer io error". mir bleibt dann nur noch ein reboot.

ich vermute, dass dieses problem am linux-kernel liegt, denn ich hatte in den letzten monaten unterschiedliche distributionen installiert, die alle reibungslos ohne diese meldung liefen. dazu gehörten unter anderem debian squeeze, sid, kubuntu und opensuse 11.2 jeweils in den 64bit-versionen.

so habe ich zunächst einen eigenen kernel jeweils mit und ohne .config des laufenden sidux-systems erzeugt, den ich leider nie bootfähig hinbekommen habe. deswegen habe ich mich dazu entschieden, den debian standard-kernel 2.6.32-trunk-amd64 in sidux zu installieren. und seitdem habe ich einen reibungslosen betrieb, ohne probleme mit dem zugriff auf meine festplatten. deswegen schließe ich daraus, dass dieses problem bei mir anscheinend etwas mit dem modifizierten sidux-kernel zu tun haben müssen.

möglicherweise liegt eine ursache auch darin, dass meine zwei festplatten einmal über sata und die andere über ide angeschlossen sind. dagegen spricht, dass andere kernel keine probleme damit haben.

fsck sagt mir, dass alles in ordnung ist. als ich sidux vor einem jahr getestet hatte, waren meine festplatten noch auf ext3 und hatten dasselbe problem.

beim googeln bin ich auch nicht richtig fündig geworden, außer vielleicht bei diesem link hier:
http://linux.derkeiler.com/Mailing-List ... 00769.html

interessant ist, dass der autor des threads anmerkt, dass bei ihm das problem immer auf sdb auftritt. das ist bei mir ebenfalls so.

hardware
  • Summary
    Computer
    Processor 2x Pentium(R) Dual-Core CPU E5200 @ 2.50GHz
    Memory 4063MB (667MB used)
    Operating System Debian GNU/Linux squeeze/sid
    Date/Time Fr 22 Jan 2010 16:32:22 CET

    Display
    Resolution 1280x1024 pixels
    OpenGL Renderer GeForce 9400 GT/PCI/SSE2
    X11 Vendor The X.Org Foundation

    Multimedia
    Audio Adapter Audigy2 - SB Audigy 4 [SB0610]

    IDE Disks
    ATAPI iHAP122 8
    MAXTOR STM3160215A

    Operating System
    Version
    Kernel Linux 2.6.32-trunk-amd64 (x86_64)
    Compiled #1 SMP Sun Jan 10 22:40:40 UTC 2010
    C Library GNU C Library version 2.10.2 (stable)
    Default C Compiler GNU C Compiler version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9)
    Distribution Debian GNU/Linux squeeze/sid
    Desktop Environment KDE 4.3.4

    lrwxrwxrwx 1 root root 10 22. Jan 22:21 27e5a4ee-30e0-4642-9fd6-6bb5966f2830 -> ../../sdb3
    lrwxrwxrwx 1 root root 10 22. Jan 22:21 68d43904-2ff2-4f33-bc15-a6dc4ca4c897 -> ../../sdb4
    lrwxrwxrwx 1 root root 10 22. Jan 22:21 69d53e0f-8427-4864-a02b-044f9ad7082d -> ../../sdb2
    lrwxrwxrwx 1 root root 10 22. Jan 22:21 ca7ae994-2d9d-4e00-8140-8eb1b7a2c9a3 -> ../../sda1
    lrwxrwxrwx 1 root root 10 22. Jan 22:21 E270D27F70D25A3D -> ../../sdb1


    # /etc/fstab - static information about the filesystems - fstab(5)
    #
    # /etc/fstab is only read by programs, and not written; it is the duty of the
    # system administrator to properly maintain this file.
    #
    # Instead of giving the device explicitly, one may indicate the filesystem
    # that is to be mounted by its UUID or VOLUME label. This will make the
    # system more robust: adding or removing a disk changes the disk device name
    # but not the filesystem UUID or VOLUME label.
    #
    # <filesystem> <mount point> <fstype> <mount options> <dump> <pass>

    /dev/disk/by-uuid/E270D27F70D25A3D /media/disk1part1 ntfs auto,users,ro,dmask=0022,fmask=0133,nls=utf8 0 0

    UUID=69d53e0f-8427-4864-a02b-044f9ad7082d / ext4 defaults,errors=remount-ro,noatime,barrier=0 0 1

    UUID=27e5a4ee-30e0-4642-9fd6-6bb5966f2830 none swap sw 0 0

    UUID=68d43904-2ff2-4f33-bc15-a6dc4ca4c897 /home2 ext4 auto,users,rw,exec,noatime 0 2

    UUID=ca7ae994-2d9d-4e00-8140-8eb1b7a2c9a3 /home ext4 defaults,noatime 0 2

    /dev/cdrom /media/cdrom udf,iso9660 noauto,ro,users 0 0

    /dev/cdrom1 /media/cdrom1 udf,iso9660 noauto,ro,users 0 0

    /dev/cdrom2 /media/cdrom2 udf,iso9660 noauto,ro,users 0 0

    /dev/cdrom3 /media/cdrom3 udf,iso9660 noauto,ro,users 0 0

    /dev/fd0 /media/fd0 auto noauto,rw,users 0 0
übrigens: ich erinnere mich da noch an ein englischsprachiges fortune-cookie, das sinngemäß sagt, dass man keinen programmierer mit einem schraubenzieher in der hemdtasche trauen soll. :D
unter anderem deswegen möchte ich meine zweite platte nicht ausbauen, damit dieser kernel eventuell fehlerfrei läuft.
von allen meinen gedanken schätze ich am meisten die interessanten

Benutzeravatar
Saxman
Beiträge: 4233
Registriert: 02.05.2005 21:53:52
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: localhost

Re: kernel muckt rum

Beitrag von Saxman » 26.01.2010 07:49:27

Ich kann dir nicht direkt helfen da ich den sidux kernel nicht kenne aber Ich würde an deiner Stelle mal ein Diff auf de configs des 2.6.32 aus sidux und dem aus debian sid laufen lassen. Vielleicht hilft dir das ja schon weiter.

Ich hab hier einen custom 2.6.30 kernel in einem ide/sata Mischbetrieb am laufen.
Bisher Problemlos.
"Unix is simple. It just takes a genius to understand its simplicity." - Dennis Ritchie

Debian GNU/Linux Anwenderhandbuch | df.de Verhaltensregeln | Anleitungen zum Review und zum Verfassen von Wiki Artikeln.

Benutzeravatar
Harakiri
Beiträge: 250
Registriert: 31.10.2009 18:00:47
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel muckt rum

Beitrag von Harakiri » 26.01.2010 11:47:06

ich hab mal die diff in nopaste reingepackt. ich hoffe dass das einigermaßen brauchbar aussieht, da ich mit nopaste und diff nicht so geübt bin.

aber wirklich auswerten kann ich die unterschiede nicht. solange ich aber mit dem debian-kernel arbeiten kann, ist das auch nicht so schlimm.

http://nopaste.debianforum.de/34215
von allen meinen gedanken schätze ich am meisten die interessanten

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Re: kernel muckt rum

Beitrag von storm » 28.01.2010 18:09:19

Harakiri hat geschrieben:ich hab mal die diff in nopaste reingepackt. ich hoffe dass das einigermaßen brauchbar aussieht, da ich mit nopaste und diff nicht so geübt bin.
Jeder fängt mal an. :)
Könntest du das diff mal als unified Ausgabe zeigen? Befehl ist ähnlich:

Code: Alles auswählen

 diff -u <version_1> <version_2> 
Das macht es besser lesbar. Die Konsequenz bei stärkeren Unterschieden wären dann ein Eigenbau-Kernel, der eine debian-config auf sidux-Quellen verwendet.

Zusätzlich zu den config-Unterschieden wäre noch interessant, ob zusätzliche patches bei sidux einfließen bzw. ob deren kernel aus einem debian-Kernel hervorgeht.


ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Benutzeravatar
Harakiri
Beiträge: 250
Registriert: 31.10.2009 18:00:47
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel muckt rum

Beitrag von Harakiri » 28.01.2010 23:57:39

hallo storm,
vielen dank für deine antwort.
ich hab das jetzt mal mit "diff -u" gemacht http://nopaste.debianforum.de/34241

details zum sidux-kernel kenne ich leider nicht. ich habe mich für sidux entschieden, da es sehr schnell läuft und eine art "geschliffene" version von sid ist. somit ist sidux nach eigenen angaben auch zu hundert prozent dabian kompatibel.

ich habe mich übrigens mittlerweile auch im kernel kompilieren versucht, bislang leider erfolglos, denn meine kernel sind dann gleich zu boot-beginn in "panic" verfallen. und das, obwohl ich zum beispiel auch die sidux .config als vorlage für menuconfig genommen hatte.

meine befürchtung ist allerdings, dass meine fragestellung hier möglicherweise den rahmen sprengen könnte. das würde auch erklären, wieso man sich im sidux-forum dazu etwas bedeckt gehalten hat. jedenfalls kann ich mich bisher mit dem debian 2.6.32-trunk-amd64 kernel als alternative gut arrangieren, denn der läuft seitdem ohne fehlermeldungen.
von allen meinen gedanken schätze ich am meisten die interessanten

Benutzeravatar
Harakiri
Beiträge: 250
Registriert: 31.10.2009 18:00:47
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel muckt rum

Beitrag von Harakiri » 07.02.2010 21:35:45

kleines update:
ich hatte heute mal die muße und die zeit dafür, mich für einen neuen anlauf zum kompilieren eines eigenen kernels aufzuraffen. und es hat geklappt! bin glücklich und stolz, mein erster selbst kompilierter linux-kernel der funktoniert. :lol:

als basis habe ich die sidux-source dafür genommen, denn die ist soweit ich weiß auch gepatcht. dazu die siduxstandard .config genommen und etwas modifiziert. allerdings war der haken an der sache, dass ich die init-ramdisk noch selber machen musste, obwohl ich laut meiner anleitung für make-kpkg die option "--initrd" mit angeführt hatte. normalerweise müsste die dann ja mit generiert werden, wenn ich das richtig verstehe.

jedenfalls habe ich den 2.6.32-Kernel jetzt auf siduxbasis, und bis jetzt läuft der auch schon eine ganze weile stabil. ich hoffe dass das so bleibt.

mich interessiert allerdings noch, ob ein selbst kompilierter kernel auch dann schneller als der vorgefertigte aus der repo ist, obwohl man die .oldconfig ohne änderung übernimmt. oder macht das normalerweise keinen unterschied?
von allen meinen gedanken schätze ich am meisten die interessanten

Benutzeravatar
catdog2
Beiträge: 5352
Registriert: 24.06.2006 16:50:03
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel muckt rum

Beitrag von catdog2 » 07.02.2010 23:31:37

mich interessiert allerdings noch, ob ein selbst kompilierter kernel auch dann schneller als der vorgefertigte aus der repo ist, obwohl man die .oldconfig ohne änderung übernimmt. oder macht das normalerweise keinen unterschied?
Wenn du die selben quellen, die selbe config und den selben compiler benutzt sollte wohl genau das selbe dabei rauskommen. ;)
Unix is user-friendly; it's just picky about who its friends are.

Benutzeravatar
Harakiri
Beiträge: 250
Registriert: 31.10.2009 18:00:47
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel muckt rum

Beitrag von Harakiri » 08.02.2010 11:54:39

okay, das hatte ich mir schon fast gedacht. insgeheim wäre es für mich ja schön gewesen daran zu glauben, dass die cpu noch irgendwelche eigenen "magischen" fähigkeiten hinzufügt. :)
von allen meinen gedanken schätze ich am meisten die interessanten

eulenreich
Beiträge: 22
Registriert: 20.12.2009 22:30:44
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel muckt rum

Beitrag von eulenreich » 14.02.2010 21:15:03

Ja, der sidux kernel benutzt viele zusätzliche patches: http://svn.berlios.de/wsvn/fullstory/li ... /changelog
Ja, es wird keinen Wert auf das ide subsystem gelegt beim sidux kernel
Ja, der debian-trunk Kernel will kompatibel sein und legt viel Wert auf das ide-subsystem
Nein, ich würde nicht das ide-subsystem mit dem sidux-kernel benutzen.
Nein, das ide-subsystem hat keine Zukunft mehr in zukünftigen Kerneln.

Wie macht man das eigentlich beide Subsysteme gleichzeitig für zwei Festplatten zu benutzen (udev?) ? Ralul

Benutzeravatar
Harakiri
Beiträge: 250
Registriert: 31.10.2009 18:00:47
Lizenz eigener Beiträge: MIT Lizenz

Re: kernel muckt rum

Beitrag von Harakiri » 15.02.2010 00:46:52

tja, mittlerweile bin ich auf linux mint 64 mit kde 4.4 umgestiegen. mit dem ubuntu-kernel, sowie mit vielen anderen os wie etwa opensuse habe ich nämlich überhaupt keine probleme.

zuvor hatte ich noch unter sidux auch den normalen sid-kernel und einige unterschiedliche selbstgebackene kernel mit geringfügigen modifikationen getestet. ich vermute allerdings, dass im sidux-paket noch einiges mehr drinsteckt, was den mischbetrieb von sata und ide stört, denn mit sidux-kernel hatte ich besagten io-error....sonstwas, mit dem sid-kernel eine etwas andere problematik. da lief das system zwar absturzfrei, jedoch hatte ich in unregelmäßigen abständen einen kompletten systemfreeze von circa 20 sekunden :cry:

das kernellog hat mir dazu als grund angezeigt "hda lost interrupt", und das auch, wenn mit hdparm dma deaktiviert war. schade eigentlich, denn sidux finde ich an sich ganz ordentlich.
von allen meinen gedanken schätze ich am meisten die interessanten

Antworten