Hier läuft ein für seine Aufgaben wohldimensionierter K6-200 auf einem
ASUS P55T2P4S mit 128 MB RAM ohne Probleme mit FreeBSD 6_2_STABLE.
(Schon seit 4_STABLE-Zeiten, die Bestandteile sind zwischendurch
allerdings gewachsen. Angefangen hat er mal als 486DX/2-66 mit
40 MB RAM. :-)

Jetzt ist beim Versuch, auf 7.0-RC1 upzudaten, folgendes Problem
aufgetreten: Der Kernel kommt ungefähr genau bis zu dem Punkt, wo
er die Timer kalibrieren will. Also direkt nach dem Versionsbanner.
:-P Wurde genau so präzisiert mit der 7.0-RC1-BootCD im verbose
mode, das letzte was er macht, ist "calibrating clock(s)...",
danach kommt nix mehr.

Hat jemand anders so ein Problem auch gehabt und gelöst? Ich dachte,
ehe ich mich mal wieder auf stable*freebsd subscribe, frage ich
hier mal nach... eventuell muß man ja einfach nur einen Kernel
mit etwas angestaubten Optionen bauen, heutzutage, wo GENERIC als
SMP-tauglich daherkommt...

OBW

Oliver B. Warzecha <obw*amarok.ping.de> wrote:

> Jetzt ist beim Versuch, auf 7.0-RC1 upzudaten, folgendes Problem
> aufgetreten: Der Kernel kommt ungefähr genau bis zu dem Punkt, wo
> er die Timer kalibrieren will. Also direkt nach dem Versionsbanner.
> :-P Wurde genau so präzisiert mit der 7.0-RC1-BootCD im verbose
> mode, das letzte was er macht, ist "calibrating clock(s)...",
> danach kommt nix mehr.

Haengt, oder braucht einfach nur lange? Wie lange hast Du
gewartet?

> Hat jemand anders so ein Problem auch gehabt und gelöst?

comp.unix.freebsd.misc und die Mailinglisten schlagen
set hint.acpi.0.disabled="1" vor.

> Ich dachte,
> ehe ich mich mal wieder auf stable*freebsd subscribe, [...]

....solltest Du vielleicht einen der List-to-News-Gateways
nutzen oder die Listenarchive auf der Webseite befragen.


Martin
--
"For the Snark's a peculiar creature, that won't
Be caught in a commonplace way.
Do all that you know, and try all that you don't;
Not a chance must be wasted to-day!"

Martin Etteldorf <etteldor*email.lu> wrote:
> Oliver B. Warzecha <obw*amarok.ping.de> wrote:
>
>> Jetzt ist beim Versuch, auf 7.0-RC1 upzudaten, folgendes Problem
>> aufgetreten: Der Kernel kommt ungefähr genau bis zu dem Punkt, wo
>> er die Timer kalibrieren will. Also direkt nach dem Versionsbanner.
>> :-P Wurde genau so präzisiert mit der 7.0-RC1-BootCD im verbose
>> mode, das letzte was er macht, ist "calibrating clock(s)...",
>> danach kommt nix mehr.
>
> Haengt, oder braucht einfach nur lange? Wie lange hast Du
> gewartet?

Mindestens eine Minute. Selbst, wenn es "nur" eine Wartezeit in
dieser Größenordung wäre, auf einer 200 MHz-Maschine wäre das in
meinen Augen immer noch ein Bug. :-P

>> Hat jemand anders so ein Problem auch gehabt und gelöst?
>
> comp.unix.freebsd.misc und die Mailinglisten schlagen
> set hint.acpi.0.disabled="1" vor.

Mal sehen, ob das tut, immerhin ist:
karnevil9# grep acpi /sys/i386/conf/KE9
karnevil9#
mein custom Kernel ohne ACPI und in DEFAULTS steht es auch nicht
drin. Aber vielleicht hilft das ja beim GENERIC und ich kann mich
von da vorarbeiten.

>> Ich dachte,
>> ehe ich mich mal wieder auf stable*freebsd subscribe, [...]
>
> ...solltest Du vielleicht einen der List-to-News-Gateways
> nutzen oder die Listenarchive auf der Webseite befragen.

Zu spät. ;-) Aber was in den Archiven steht, wird von Google
indiziert, und wenn mir da die falschen Suchbegriffe eingefallen
sind, dann finde ich direkt auch nix. :-(

Gruß,
OBW

Oliver B. Warzecha <obw*amarok.ping.de> wrote:
> Martin Etteldorf <etteldor*email.lu> wrote:
>> Oliver B. Warzecha <obw*amarok.ping.de> wrote:
>>
>>> Jetzt ist beim Versuch, auf 7.0-RC1 upzudaten, folgendes Problem
>>> aufgetreten: Der Kernel kommt ungefähr genau bis zu dem Punkt, wo
>>> er die Timer kalibrieren will. Also direkt nach dem Versionsbanner.
>>> :-P Wurde genau so präzisiert mit der 7.0-RC1-BootCD im verbose
>>> mode, das letzte was er macht, ist "calibrating clock(s)...",
>>> danach kommt nix mehr.
>>
>> Haengt, oder braucht einfach nur lange? Wie lange hast Du
>> gewartet?
>
> Mindestens eine Minute.

Warte mal 3-5 Minuten,

> Selbst, wenn es "nur" eine Wartezeit in
> dieser Größenordung wäre, auf einer 200 MHz-Maschine wäre das in
> meinen Augen immer noch ein Bug. :-P

Mach 'nen PR auf.

>>> Hat jemand anders so ein Problem auch gehabt und gelöst?
>>
>> comp.unix.freebsd.misc und die Mailinglisten schlagen
>> set hint.acpi.0.disabled="1" vor.
>
> Mal sehen, ob das tut, immerhin ist:
> karnevil9# grep acpi /sys/i386/conf/KE9
> karnevil9#
> mein custom Kernel ohne ACPI

Glaube ich Dir erst, wenn Du mir auch den Output von kldstat,
einen "grep acpi /boot/loader.conf" und einen getenv vom loader-
Prompt lieferst.
Wer behauptet denn, dass ACPI statisch in den Kernel rein muss?
ACPI wird mindestens seit FreeBSD 6 als Modul geladen.


Martin
--
"For the Snark's a peculiar creature, that won't
Be caught in a commonplace way.
Do all that you know, and try all that you don't;
Not a chance must be wasted to-day!"

Martin Etteldorf <etteldor*email.lu> wrote:
> Warte mal 3-5 Minuten,

Aua. Werde ich nachher mal probieren. kernel.70GEN laden und abwarten...

>> Mal sehen, ob das tut, immerhin ist:
>> karnevil9# grep acpi /sys/i386/conf/KE9
>> karnevil9#
>> mein custom Kernel ohne ACPI
>
> Glaube ich Dir erst, wenn Du mir auch den Output von kldstat,
> einen "grep acpi /boot/loader.conf" und einen getenv vom loader-
> Prompt lieferst.
> Wer behauptet denn, dass ACPI statisch in den Kernel rein muss?
> ACPI wird mindestens seit FreeBSD 6 als Modul geladen.

Das hat er auch mindestens einmal versucht, aber laut asus.de:
P/I-P55T2P4S APM
wohl erfolglos. Irgendein Kernel hat zwischendurch auch ein apm-Modul
geladen, bei "meinen" ist das fest drin.
karnevil9# kldstat
Id Refs Address Size Name
1 16 0xc0400000 40bc28 kernel
2 1 0xc080c000 169a8 geom_mirror.ko
3 1 0xc0823000 7960 geom_stripe.ko
4 1 0xc082b000 e218 if_ed.ko
5 4 0xc1b1f000 c000 netgraph.ko
6 1 0xc1b30000 4000 ng_ether.ko
7 1 0xc1b34000 6000 ng_pppoe.ko
8 1 0xc1b3a000 4000 ng_socket.ko
9 1 0xc1c84000 4000 logo_saver.ko

Das ist der Rechner unter 6.2-p8, die Config ist quasi identisch,
da ich die alte Datei genommen und geupdatet habe.

(Wenn ACPI ohne ACPI-fähiges Motherboard gehen sollte, kann ich
ja auch mal versuchen, ein paar GB auf den Firewire-Platten
abzuspeichern, die ich nicht hab ;-)

OBW

Oliver B. Warzecha <obw*amarok.ping.de> wrote:

> (Wenn ACPI ohne ACPI-fähiges Motherboard gehen sollte, kann ich
> ja auch mal versuchen, ein paar GB auf den Firewire-Platten
> abzuspeichern, die ich nicht hab ;-)

Es geht nicht darum, ob es funktioniert, sondern darum, ob das
Modul geladen wird oder nicht. Das Modul kannst Du ja auch laden,
ohne dass die Hardware eine entsprechende Funktion unterstuetzt.

Und genau diese Konstellation (acpi.ko geladen ohne dass die Hard-
ware ACPI kann) macht eben bekanntermassen Aerger. Dementsprechend
wuerde ich eben erstmal dafuer sorgen, dass das Modul bei der 7.0-
Installation nicht geladen wird.



Martin

--
"For the Snark's a peculiar creature, that won't
Be caught in a commonplace way.
Do all that you know, and try all that you don't;
Not a chance must be wasted to-day!"

Martin Etteldorf <etteldor*email.lu> wrote:
> Und genau diese Konstellation (acpi.ko geladen ohne dass die Hard-
> ware ACPI kann) macht eben bekanntermassen Aerger. Dementsprechend
> wuerde ich eben erstmal dafuer sorgen, dass das Modul bei der 7.0-
> Installation nicht geladen wird.

Wurde wirklich nicht geladen, aber danke für den Tipp mit den Hints.
Sicher ist sicher.

Aber Du hattest recht, nach ca. 4(?) Minuten (Ich habe den Kernel geladen
und dann irgendwas anderes gemacht) ging das Booten weiter. Der Fehler
liegt wohl hier:

471 if (!(rtcin(RTC_STATUSD) & RTCSD_PWR))
472 goto fail;
473 timeout = 100000000;
474
475 /* Read the mc146818A seconds counter. */
476 for (;;) {
477 if (!(rtcin(RTC_STATUSA) & RTCSA_TUP)) {
478 sec = rtcin(RTC_SEC);
479 break;
480 }
481 if (--timeout == 0)
482 goto fail;
483 }

Die Erkennung in Zeile 471 scheint nicht zu klappen und er wartet dann
die lange Schleife. Die einzige Änderung zwischen RELENG_6_2 und
RELENG_7_0, die das betreffen könnte, sind ein buggefixtes
rtcin(), so weit ich das sehe. Es könnte natürlich noch sein, dass
er durch die erste Schleife durchkommt, und dann in einer der
folgenden verreckt. Und die dauern jeweils MAXINT Durchläufe...

/usr/obj ist noch gut gefüllt, wo muß man denn was make(1)n,
wenn man da Debug-printf()s einfügt? Ich will nicht den ganzen
Kernel nochmal bauen müssen, auf der Kiste dauert das... :-P

Und könnte das ganze evtl. irgendwie anders zu beheben sein
und ist das gar kein Bug?

OBW

Oliver B. Warzecha <obw*amarok.ping.de> wrote:

> /usr/obj ist noch gut gefüllt, wo muß man denn was make(1)n,
> wenn man da Debug-printf()s einfügt? Ich will nicht den ganzen
> Kernel nochmal bauen müssen, auf der Kiste dauert das... :-P

Solange Du keinen "make cleandepend ; make depend" machst, baut er
nur die Sachen neu, die geaendert wurden. Sollte, wenn Du nur eine
Datei aenderst, demnach recht fix gehen.

> Und könnte das ganze evtl. irgendwie anders zu beheben sein
> und ist das gar kein Bug?

PR aufmachen und gucken, was zurueckkommt? So habe ich jedenfalls
meinem 7.0 die Bauchlandungen bei Googleearth abgewoehnt.



Martin
--
"For the Snark's a peculiar creature, that won't
Be caught in a commonplace way.
Do all that you know, and try all that you don't;
Not a chance must be wasted to-day!"

Martin Etteldorf <etteldor*email.lu> wrote:
> Oliver B. Warzecha <obw*amarok.ping.de> wrote:
>
>> /usr/obj ist noch gut gefüllt, wo muß man denn was make(1)n,
>> wenn man da Debug-printf()s einfügt? Ich will nicht den ganzen
>> Kernel nochmal bauen müssen, auf der Kiste dauert das... :-P
>
> Solange Du keinen "make cleandepend ; make depend" machst, baut er
> nur die Sachen neu, die geaendert wurden. Sollte, wenn Du nur eine
> Datei aenderst, demnach recht fix gehen.

Ich hatte vorhin was mit -DNO_KERNELCLEAN und -DNO_KERNELDEPEND
angeworfen. Allerdings hatte ich mich vertippt( KERNEL_DEPEND),
da fing er an, irgendwelche Dependencies zu berechnen. :-(
Abgebrochen, nochmal mit richtigen Defines gestartet, jetzt macht
er zumindest das nochmal. Mal sehen, was das wird, wenn er anfängt
zu compilieren, mache ich das halt irgendwann am Wochenende weiter.

Oha, er ist schon durch, ackert nur noch die ganzen Module durch,
puh! :-)

>> Und könnte das ganze evtl. irgendwie anders zu beheben sein
>> und ist das gar kein Bug?
>
> PR aufmachen und gucken, was zurueckkommt? So habe ich jedenfalls
> meinem 7.0 die Bauchlandungen bei Googleearth abgewoehnt.

Ja, darauf wird es wohl hinauslaufen, wobei ich zumindest die Stelle
noch eingrenzen wollte, sind jetzt ein paar printf()s drin.

OBW