Re: setting up kernel 2.4
Vittorio wrote:
As someone in this list pointed out the troubles to boot either a
2.4.20 or 2.4.18 kernel with my digital alpha 500 is due to the
core_cia.c module (included in the kernel), which fails to recognize
the hardware causing a kernel panic failure.
I've downloaded the debian 2.4.18. source original and diff tarballs
and have had a go at compiling the unchanged original 2.4.18 kernel
but the result has been the same, a kernel panic failure!
Please help
Ciao
Vittorio
Vittorio,
The "problem" with the core_cia.c module is limited to those computers
with the 21171 (CIA-1) chipset. Later chipsets (21172, etc) were
apparently NOT affected. See my message in the archives of this list
dated 10 May 2002 for a discussion of my experiences in "layman's" terms
<g>. I don't really know if your computer has this chipset or not. At
the time, this "problem" was only reported on the Alpha 300-XL platform.
About the only way I know to determine which one you have is to pull
the cover and look at the chips for numbers.
IF you have the 21171 chipset, you will have to make some edits to the
core_cia.c module in the kernel SOURCE tree, THEN compile. The mods I
made are listed in the message mentioned above, which you can make
manually via editing the file. Alternatively, (and probably more
correct) you can use the attached "patch" created by Jay Estabrook.
This has only been "tested" on the 2.4.18 kernel. I can't really vouch
for how it works on later kernels.
BTW, there are other causes for a kernel panic during boot that I ran
into. I had some initial problems with getting initrd working AFTER I
had a working 2.4.18 kernel compiled that didn't use it. Other messages
in the archives helped me solve that "problem". The problem here was
mainly getting the right string to pass the initrd info to MILO. If you
are using the SRM console, I can't help you there since I don't have it
on my computer.
HTH,
-Don Spoon-
diff -ur old/arch/alpha/kernel/core_cia.c new/arch/alpha/kernel/core_cia.c
--- old/arch/alpha/kernel/core_cia.c Sun Oct 21 13:30:58 2001
+++ new/arch/alpha/kernel/core_cia.c Tue May 28 15:02:42 2002
@@ -370,7 +370,7 @@
}
static inline void
-cia_prepare_tbia_workaround(void)
+cia_prepare_tbia_workaround(int cia_rev, int is_pyxis)
{
unsigned long *ppte, pte;
long i;
@@ -382,10 +382,20 @@
for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
ppte[i] = pte;
- *(vip)CIA_IOC_PCI_W1_BASE = CIA_BROKEN_TBIA_BASE | 3;
- *(vip)CIA_IOC_PCI_W1_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
- & 0xfff00000;
- *(vip)CIA_IOC_PCI_T1_BASE = virt_to_phys(ppte) >> 2;
+ if (is_pyxis || cia_rev != 1) {
+ /* We can use W1 for SG on PYXIS/CIA rev 2. */
+ *(vip)CIA_IOC_PCI_W1_BASE = CIA_BROKEN_TBIA_BASE | 3;
+ *(vip)CIA_IOC_PCI_W1_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
+ & 0xfff00000;
+ *(vip)CIA_IOC_PCI_T1_BASE = virt_to_phys(ppte) >> 2;
+ } else {
+ /* CIA rev 1 can't use W1 or W2 for SG, apparently,
+ so use W3, which we made sure is not used for DAC. */
+ *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBIA_BASE | 3;
+ *(vip)CIA_IOC_PCI_W3_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
+ & 0xfff00000;
+ *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(ppte) >> 2;
+ }
}
static void __init
@@ -715,8 +725,14 @@
are compared against W_DAC. We can, however, directly map 4GB,
which is better than before. However, due to assumptions made
elsewhere, we should not claim that we support DAC unless that
- 4GB covers all of physical memory. */
- if (is_pyxis || max_low_pfn > (0x100000000 >> PAGE_SHIFT)) {
+ 4GB covers all of physical memory.
+
+ Also, don't do DAC on CIA rev 1, it has other problems and is
+ unlikely to have more than 2GB of memory anyway, so direct is
+ fine.
+ */
+ if (cia_rev == 1 || is_pyxis ||
+ max_low_pfn > (0x100000000 >> PAGE_SHIFT)) {
*(vip)CIA_IOC_PCI_W3_BASE = 0;
} else {
*(vip)CIA_IOC_PCI_W3_BASE = 0x00000000 | 1 | 8;
@@ -728,7 +744,7 @@
}
/* Prepare workaround for apparently broken tbia. */
- cia_prepare_tbia_workaround();
+ cia_prepare_tbia_workaround(cia_rev, is_pyxis);
}
void __init
Reply to: