PROBLEM: test13-pre3, e2fs corruption
1. test13-pre3, e2fs corruption 2. running my box 4h 30min i wanted edit some files, the filenames were wrong and other files didnt have the correct data. i unmounted the drive with the data and a e2fsck said wrong group names...bad superblock... after reboot without check or repair on 2.2.18 no problems reported and all my data are correct. some days before i tried mount my atapi-cdrom and my box hangs completly with test12 or test13-pre1, couldnt reproduce it yet. (no overclocking) 3. e2fs filesystem 4. Linux version 2.4.0-test13-pre3 (root@apollo) (gcc version 2.95.2 19991024 (release)) #3 SMP Mon Dec 18 02:30:28 CET 2000 5. none 6. none 7. none 7.1 -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux apollo 2.4.0-test13-pre3 #3 SMP Mon Dec 18 02:30:28 CET 2000 i586 unknown Kernel modules 2.3.11 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.9.5.0.24 Linux C Libraryx 1 root root 4070406 Jul 30 21:41 /lib/libc.so.6 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10m Net-tools 1.56 Kbd0.99 Sh-utils 2.0 Modules Loaded 7.2 processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 400.906 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips: 799.54 7.3 -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0213-0213 : isapnp read 02f8-02ff : serial(auto) 0376-0376 : ide1 0378-037a : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0a79-0a79 : isapnp write 0cf8-0cff : PCI conf1 5c20-5c3f : Acer Laboratories Inc. [ALi] M7101 PMU d000-d00f : Acer Laboratories Inc. [ALi] M5229 IDE d400-d43f : Ensoniq ES1371 [AudioPCI-97] d400-d43f : es1371 d800-d8ff : Realtek Semiconductor Co., Ltd. RTL-8139 d800-d8ff : eth0 -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-07ffbfff : System RAM 0010-002ef4af : Kernel code 002ef4b0-0031193f : Kernel data 07ffc000-07ffefff : ACPI Tables 07fff000-07ff : ACPI Non-volatile Storage de00-deff : Realtek Semiconductor Co., Ltd. RTL-8139 de00-deff : eth0 df00-dfff : PCI Bus #01 df00-df7f : Matrox Graphics, Inc. MGA G400 AGP df80-df803fff : Matrox Graphics, Inc. MGA G400 AGP e000-e3ff : Acer Laboratories Inc. [ALi] M1541 e5f0-e7ff : PCI Bus #01 e600-e7ff : Matrox Graphics, Inc. MGA G400 AGP - : reserved 7.5 00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04) Subsystem: Acer Laboratories Inc. [ALi] ALI M1541 Aladdin V/V+ AGP System Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- FastB2B- 00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU Subsystem: Acer Laboratories Inc. [ALi] ALI M7101 Power Management Controller Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
PROBLEM: test13-pre3, e2fs corruption
1. test13-pre3, e2fs corruption 2. running my box 4h 30min i wanted edit some files, the filenames were wrong and other files didnt have the correct data. i unmounted the drive with the data and a e2fsck said wrong group names...bad superblock... after reboot without check or repair on 2.2.18 no problems reported and all my data are correct. some days before i tried mount my atapi-cdrom and my box hangs completly with test12 or test13-pre1, couldnt reproduce it yet. (no overclocking) 3. e2fs filesystem 4. Linux version 2.4.0-test13-pre3 (root@apollo) (gcc version 2.95.2 19991024 (release)) #3 SMP Mon Dec 18 02:30:28 CET 2000 5. none 6. none 7. none 7.1 -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux apollo 2.4.0-test13-pre3 #3 SMP Mon Dec 18 02:30:28 CET 2000 i586 unknown Kernel modules 2.3.11 Gnu C 2.95.2 Gnu Make 3.79.1 Binutils 2.9.5.0.24 Linux C Libraryx 1 root root 4070406 Jul 30 21:41 /lib/libc.so.6 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10m Net-tools 1.56 Kbd0.99 Sh-utils 2.0 Modules Loaded 7.2 processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping: 12 cpu MHz : 400.906 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips: 799.54 7.3 -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0213-0213 : isapnp read 02f8-02ff : serial(auto) 0376-0376 : ide1 0378-037a : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0a79-0a79 : isapnp write 0cf8-0cff : PCI conf1 5c20-5c3f : Acer Laboratories Inc. [ALi] M7101 PMU d000-d00f : Acer Laboratories Inc. [ALi] M5229 IDE d400-d43f : Ensoniq ES1371 [AudioPCI-97] d400-d43f : es1371 d800-d8ff : Realtek Semiconductor Co., Ltd. RTL-8139 d800-d8ff : eth0 -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-07ffbfff : System RAM 0010-002ef4af : Kernel code 002ef4b0-0031193f : Kernel data 07ffc000-07ffefff : ACPI Tables 07fff000-07ff : ACPI Non-volatile Storage de00-deff : Realtek Semiconductor Co., Ltd. RTL-8139 de00-deff : eth0 df00-dfff : PCI Bus #01 df00-df7f : Matrox Graphics, Inc. MGA G400 AGP df80-df803fff : Matrox Graphics, Inc. MGA G400 AGP e000-e3ff : Acer Laboratories Inc. [ALi] M1541 e5f0-e7ff : PCI Bus #01 e600-e7ff : Matrox Graphics, Inc. MGA G400 AGP - : reserved 7.5 00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04) Subsystem: Acer Laboratories Inc. [ALi] ALI M1541 Aladdin V/V+ AGP System Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort+ SERR- PERR- Latency: 64 Region 0: Memory at e000 (32-bit, non-prefetchable) [size=64M] Capabilities: [b0] AGP version 1.0 Status: RQ=28 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: e000-dfff Memory behind bridge: df00-dfff Prefetchable memory behind bridge: e5f0-e7ff BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- 00:03.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU Subsystem: Acer Laboratories Inc. [ALi] ALI M7101 Power Management Controller Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- 00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev c3) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort+ MAbort
Re: Startup IPI (was: Re: test13-pre3)
On Wed, 20 Dec 2000, Petr Vandrovec wrote: > /usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing Well, the test looks reasonable if the system load is low. Still the performance is surprisingly low -- after changing the transfer width to 16 bits I ran the test on my dual P5MMX system equipped with an old ISA VGA card and I achieved 10.74ms for VGA RAM accesses and 586.6us for uncached main memory accesses. > by 1000 I get 3.4ms... Maybe I should complain to VIA or to Matrox that > it is piece of crap ? For VIA -- definitely. I don't think Matrox is at fault, though. > My order was simple: no rambus memory, dual PIII at least on 800MHz > and UDMA66. Yes, maybe I should buy ServerWorks instead of VIA, but > I hoped... At least ServerWorks claims they are willing to cooperate with us although results seem to be questionable so far... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Wed, 20 Dec 2000, Petr Vandrovec wrote: /usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing Well, the test looks reasonable if the system load is low. Still the performance is surprisingly low -- after changing the transfer width to 16 bits I ran the test on my dual P5MMX system equipped with an old ISA VGA card and I achieved 10.74ms for VGA RAM accesses and 586.6us for uncached main memory accesses. by 1000 I get 3.4ms... Maybe I should complain to VIA or to Matrox that it is piece of crap ? For VIA -- definitely. I don't think Matrox is at fault, though. My order was simple: no rambus memory, dual PIII at least on 800MHz and UDMA66. Yes, maybe I should buy ServerWorks instead of VIA, but I hoped... At least ServerWorks claims they are willing to cooperate with us although results seem to be questionable so far... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test13-pre3 drivers/char/Makefile and CONFIG_DRM_MGA=m
Hello, When I use 'make menuconfig' on 2.4.0-test13-pre3 to select DRM and the Matrox DRM driver as a module, I get a .config with CONFIG_DRM=y and CONFIG_DRM_MGA=m. However, this causes drivers/char/Makefile to skip the drm subdirectory when compiling modules: its only reference to CONFIG_DRM is the line 'subdir-$(CONFIG_DRM) += drm' and 'make menuconfig' does not allow me to select 'm' for CONFIG_DRM. I don't know enough about the kernel Makefiles to figure out the proper solution, but I was able to get the modules compiled by adding the line 'mod-subdirs += drm' to drivers/char/Makefile. This is not the proper solution, I expect, as now 'make modules' will enter the driver/char/drm subdirectory even if CONFIG_DRM=n. Cheers, Wayne --- drivers/char/Makefile~ Wed Dec 20 11:16:59 2000 +++ drivers/char/Makefile Wed Dec 20 11:21:54 2000 @@ -154,6 +154,7 @@ subdir-$(CONFIG_FTAPE) += ftape subdir-$(CONFIG_DRM) += drm +mod-subdirs += drm subdir-$(CONFIG_PCMCIA) += pcmcia subdir-$(CONFIG_AGP) += agp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 20 Dec 00 at 19:52, Maciej W. Rozycki wrote:
> > it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture
> > take 3.48ms, and this does not correspond with needed 200us udelay.
>
> Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a
> read or write cycle lasts for a single clock tick (I don't know exact AGP
> specs -- please correct me if I'm wrong), I find 0x1300 cycles to finish
> in about 73usecs. The loop execution overhead may double the result and
> it will still fit within 300usecs.
It is easy:
int mfd;
volatile unsigned long* memory;
int i;
mfd = open("/dev/mem", O_RDWR);
memory = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, mfd, 0x000B8000);
close(mfd);
for (i = 0; i < 0x1300 * 1000; i++) {
*memory = i;
*memory;
}
munmap(memory, 4096);
/usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing
by 1000 I get 3.4ms... Maybe I should complain to VIA or to Matrox that
it is piece of crap ?
> > Without VIA datasheet I cannot try to disable some PCI features to find
> > which one is culprit, so I'm sorry.
>
> But you may complain to the manufacturer and/or change hardware. I'm
> still uncertain the delay should stay in...
My order was simple: no rambus memory, dual PIII at least on 800MHz
and UDMA66. Yes, maybe I should buy ServerWorks instead of VIA, but
I hoped...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote: > I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR', > yes (as verified in generated code...)? No change, still dies, as expected > (do not forget that before it dies, it can do ~0x1300 write-read cycles I've forgotten indeed... > from videomemory (AGP4x), so secondary CPU just does some thinking before This might be the time needed to deliver the IPI. Remember that the inter-APIC bus is serial and not that fast. > it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture > take 3.48ms, and this does not correspond with needed 200us udelay. Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a read or write cycle lasts for a single clock tick (I don't know exact AGP specs -- please correct me if I'm wrong), I find 0x1300 cycles to finish in about 73usecs. The loop execution overhead may double the result and it will still fit within 300usecs. > Maybe chipset decides to do something when second CPU cannot obtain > bus access in 10 pci cycles?). I guess a certain initial cycle from the AP confuses the chipset somehow. > Do you (or anyone else) have code which can dump MTRR registers of each > of CPU before mtrr driver takes over them? At least first CPU does not have > any problem... A brief look at arch/i386/kernel/mtrr.c reveals the bootstrap CPU's settings do not get changed. As a result they may always be fetched from the /proc filesystem. For APs you probably need to tweak sources. > I even placed 'wbinvd' and 'wbinvd; cpuid' before sending startup IPI, > but it does not matter. Secondary CPU just does not finish even first > instruction when first CPU reads from videoram again and again. Well, the CPU obeys the writeback and the invalidation, but does the chipset? > Without VIA datasheet I cannot try to disable some PCI features to find > which one is culprit, so I'm sorry. But you may complain to the manufacturer and/or change hardware. I'm still uncertain the delay should stay in... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote: I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR', yes (as verified in generated code...)? No change, still dies, as expected (do not forget that before it dies, it can do ~0x1300 write-read cycles I've forgotten indeed... from videomemory (AGP4x), so secondary CPU just does some thinking before This might be the time needed to deliver the IPI. Remember that the inter-APIC bus is serial and not that fast. it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture take 3.48ms, and this does not correspond with needed 200us udelay. Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a read or write cycle lasts for a single clock tick (I don't know exact AGP specs -- please correct me if I'm wrong), I find 0x1300 cycles to finish in about 73usecs. The loop execution overhead may double the result and it will still fit within 300usecs. Maybe chipset decides to do something when second CPU cannot obtain bus access in 10 pci cycles?). I guess a certain initial cycle from the AP confuses the chipset somehow. Do you (or anyone else) have code which can dump MTRR registers of each of CPU before mtrr driver takes over them? At least first CPU does not have any problem... A brief look at arch/i386/kernel/mtrr.c reveals the bootstrap CPU's settings do not get changed. As a result they may always be fetched from the /proc filesystem. For APs you probably need to tweak sources. I even placed 'wbinvd' and 'wbinvd; cpuid' before sending startup IPI, but it does not matter. Secondary CPU just does not finish even first instruction when first CPU reads from videoram again and again. Well, the CPU obeys the writeback and the invalidation, but does the chipset? Without VIA datasheet I cannot try to disable some PCI features to find which one is culprit, so I'm sorry. But you may complain to the manufacturer and/or change hardware. I'm still uncertain the delay should stay in... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 20 Dec 00 at 19:52, Maciej W. Rozycki wrote:
it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture
take 3.48ms, and this does not correspond with needed 200us udelay.
Hmm, how do you calculate the time? Assuming AGP4x runs at 133MHz and a
read or write cycle lasts for a single clock tick (I don't know exact AGP
specs -- please correct me if I'm wrong), I find 0x1300 cycles to finish
in about 73usecs. The loop execution overhead may double the result and
it will still fit within 300usecs.
It is easy:
int mfd;
volatile unsigned long* memory;
int i;
mfd = open("/dev/mem", O_RDWR);
memory = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, mfd, 0x000B8000);
close(mfd);
for (i = 0; i 0x1300 * 1000; i++) {
*memory = i;
*memory;
}
munmap(memory, 4096);
/usr/bin/time says that program runs for 3.40 - 3.56secs, so after dividing
by 1000 I get 3.4ms... Maybe I should complain to VIA or to Matrox that
it is piece of crap ?
Without VIA datasheet I cannot try to disable some PCI features to find
which one is culprit, so I'm sorry.
But you may complain to the manufacturer and/or change hardware. I'm
still uncertain the delay should stay in...
My order was simple: no rambus memory, dual PIII at least on 800MHz
and UDMA66. Yes, maybe I should buy ServerWorks instead of VIA, but
I hoped...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test13-pre3 drivers/char/Makefile and CONFIG_DRM_MGA=m
Hello, When I use 'make menuconfig' on 2.4.0-test13-pre3 to select DRM and the Matrox DRM driver as a module, I get a .config with CONFIG_DRM=y and CONFIG_DRM_MGA=m. However, this causes drivers/char/Makefile to skip the drm subdirectory when compiling modules: its only reference to CONFIG_DRM is the line 'subdir-$(CONFIG_DRM) += drm' and 'make menuconfig' does not allow me to select 'm' for CONFIG_DRM. I don't know enough about the kernel Makefiles to figure out the proper solution, but I was able to get the modules compiled by adding the line 'mod-subdirs += drm' to drivers/char/Makefile. This is not the proper solution, I expect, as now 'make modules' will enter the driver/char/drm subdirectory even if CONFIG_DRM=n. Cheers, Wayne --- drivers/char/Makefile~ Wed Dec 20 11:16:59 2000 +++ drivers/char/Makefile Wed Dec 20 11:21:54 2000 @@ -154,6 +154,7 @@ subdir-$(CONFIG_FTAPE) += ftape subdir-$(CONFIG_DRM) += drm +mod-subdirs += drm subdir-$(CONFIG_PCMCIA) += pcmcia subdir-$(CONFIG_AGP) += agp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
The saga continues into test13-pre3-ac3: (last good tdfx.o was from test12) # uname -a Linux jyro.mirai.cx 2.4.0-test13pre3-ac3 #1 Tue Dec 19 21:26:36 PST 2000 i586 unknown # lsmod Module Size Used by iptable_filter 1872 0 (autoclean) (unused) ip_nat_ftp 3424 0 (unused) iptable_nat12672 1 [ip_nat_ftp] ip_conntrack_ftp2048 0 (unused) ip_conntrack 13056 2 [ip_nat_ftp iptable_nat ip_conntrack_ftp] ip_tables 10624 4 [iptable_filter iptable_nat] ide-scsi8096 0 8139too15024 2 (autoclean) emu10k145248 0 # modprobe tdfx /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol remap_page_range /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __wake_up /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol mtrr_add /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __generic_copy_from_user /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol schedule /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol kmalloc /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol si_meminfo /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol create_proc_entry /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol inter_module_put /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __get_free_pages /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol boot_cpu_data /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol inter_module_get /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol remove_wait_queue /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol high_memory /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol iounmap /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol free_pages /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __ioremap /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol del_timer /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol interruptible_sleep_on /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __pollwait /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol kfree /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol remove_proc_entry /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol pci_find_slot /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol kill_fasync /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol fasync_helper /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol add_wait_queue /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol do_mmap_pgoff /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol mem_map /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol sprintf /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol jiffies /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol printk /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol add_timer /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __generic_copy_to_user /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: insmod /lib/mo dules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o failed Hope this helps - jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote: [snip of Petr's system info] > Okay. Mine, as far as I can tell, only depends on the L2 cache being set > to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under > 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS > for this motherboard available. It's a TD5TH version 1.1 > > H. Have you tried booting with an hercmono (if you can get your paws > on one, that is)?. > > > Right after 'Freeing unused kernel memory...' > I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 > without fbcon. With fbcon it would appear to switch video mode and > freeze with a black screen with cursor at the bottom, at that point. > > And then I get an oops dump in the swapper task. I'll try decoding it in a > little while, since I'll have to manually input it. Here we go: I DID have to copy it onto paper and type it in after rebooting. >>EIP; c01354a6<= Trace; c0217d72 Trace; c02180da Trace; c0186e85 Trace; c019e238 Trace; c01a22b7 Trace; c019fb0e Trace; c01a21d0 Trace; c010c2d1 Trace; c010c4b8 Trace; c0108d40 Trace; c010ac00 Trace; c0108d40 Trace; c0108dbc Trace; c0108dd2 Trace; c0105000 Trace; c01001cf Code; c01354a6 <_EIP>: Code; c01354a6<= 0: 0f 0b ud2a <= Code; c01354a8 2: 83 c4 0c add$0xc,%esp Code; c01354ab 5: 90nop Code; c01354ac 6: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c01354b0 a: 8d 5e 28 lea0x28(%esi),%ebx Code; c01354b3 d: 8d 46 2c lea0x2c(%esi),%eax Code; c01354b6 10: 39 46 2c cmp%eax,0x2c(%esi) Code; c01354b9 13: 74 00 je 15 <_EIP+0x15> c01354bb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ PATCH ] against 2.4.0-test13-pre3 - fixes builds for ALPHA
Hmm. Gotta build setup-*.c somehow. Alpha Config defines ALPHA_FOO (Generic or specific model #) but not vanilla alpha. --- linux.orig/arch/alpha/config.in Tue Dec 19 14:54:14 2000 +++ linux/arch/alpha/config.in Tue Dec 19 14:53:05 2000 @@ -4,6 +4,7 @@ # define_bool CONFIG_UID16 n +define_bool CONFIG_ALPHA y mainmenu_name "Kernel configuration of Linux for Alpha machines" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote: > On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote: > > > > Pardon me for not fully groking the issues here and possibly coming to a > > wrong conclusion, but this has to do with SMP systems crashing at APIC > > init time, just before penguin display (with fbcon at least)? If so, I > > have a board that does this with certain cache settings made in the BIOS. > > It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. > > I'm using BIOS dated 19/07/2000, last week it was latest BIOS on Gigabyte > site for 6VXD7 (two PIII/800). I did not looked for updates today yet. > > I tried to change C2P Concurrency & Master (en/dis), AGP Mode (1x/2x/4x), > Power mgmt - Display Activity (monitor/ignore), PNP OS (yes/no) > (24 combinations total), but any combination dies if there are read > accesses to videoram during startup. Today I finally digged out some > old ISA VGA (Realtek), plugged it in and - it dies too. So it does not > depend on bus type. Okay. Mine, as far as I can tell, only depends on the L2 cache being set to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS for this motherboard available. It's a TD5TH version 1.1 H. Have you tried booting with an hercmono (if you can get your paws on one, that is)?. Right after 'Freeing unused kernel memory...' I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 without fbcon. With fbcon it would appear to switch video mode and freeze with a black screen with cursor at the bottom, at that point. And then I get an oops dump in the swapper task. I'll try decoding it in a little while, since I'll have to manually input it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 19 Dec 00 at 19:30, Maciej W. Rozycki wrote: > > When I replaced address with 0xC01B8000 (some cachable memory), it worked > > fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe > > it is just set as cacheable in chipset), it works too. > > Hmm, a read from an uncached location could result in sending delayed > APIC writes to the bus in case of an incorrect MTRR setting for the APIC > space. Could you please disable CONFIG_X86_GOOD_APIC? This will result > in using locked cycles for APIC writes, i.e. immediate bus accesses. I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR', yes (as verified in generated code...)? No change, still dies, as expected (do not forget that before it dies, it can do ~0x1300 write-read cycles from videomemory (AGP4x), so secondary CPU just does some thinking before it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture take 3.48ms, and this does not correspond with needed 200us udelay. Maybe chipset decides to do something when second CPU cannot obtain bus access in 10 pci cycles?). > Please also check MTRR settings, especially for the APIC range. They > might need fixing. Do you (or anyone else) have code which can dump MTRR registers of each of CPU before mtrr driver takes over them? At least first CPU does not have any problem... > > at the beginning of trampoline.S, and then boot with 'no-scroll', but > > character in upper left corner did not change, so secondary CPU probably > > even did not start code fetches. That's all I can say until > > I put non-AGP card into the box (but I need AGP, so it is not real > > option). > > An easier way to check an application processor is alive could be > enabling the speaker -- after setting it up by the bootstrap CPU it only > takes three instructions to set bits 0 and 1 of port 0x61 and the result > is not volatile. A LED diagnostic display would be better, but typical > PCs don't have one, unfortunately. Fortunately secondary CPU starts with AL & 3 == 0, so it is just one 'outb %al,$0x61' instruction. When first CPU reads memory in loop, it beeps and beeps and beeps. If first CPU does 'udelay(300);', it works fine (I put mdelay(100) after enabling speaker, so I hear short 1000Hz beep during boot). So secondary CPU does not correctly execute even first instruction. But it either locks bus forever (looks like that because of ATX poweroff button does not work anymore), or confuses first CPU so much that it also cannot continue... > > Yeah. Just do not read video memory when another CPU starts. I'll try > > disabling cache on both CPUs, maybe it will make some difference, as > > secondary CPU should start with caches disabled. But maybe that it is > > just broken AGP bus, and nothing else. But until I find what's really > > broken on my hardware, I'd like to leave 'udelay(300)' in. > > If the problem is with write combining then disabling the cache won't > help, I'm afraid. Read loop reads one short from one constant address, so any write* should not make any problem. > > instead of string as soon as second CPU started (no, it did not race due > > to missing console_lock; before first printk() secondary CPU should fill > > whole screen with letter '2'. It did not). ^ digit. I'm sorry ;-) > > I would still verify (i.e. with the speaker) that's really the second CPU > causing the corruption. I even placed 'wbinvd' and 'wbinvd; cpuid' before sending startup IPI, but it does not matter. Secondary CPU just does not finish even first instruction when first CPU reads from videoram again and again. Without VIA datasheet I cannot try to disable some PCI features to find which one is culprit, so I'm sorry. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
success with test13-pre3
I'm glad to report that 2.4.0-test13-pre3 fixes the lockup (and odd Oops messages) problems I had from test12 til test13-pre2. I've been running it on both of my computers for a day and a half and everything is OK. At first, we thought it had something to do with the modules I was using, but I was unable to confirm that, so I suspected it was something to do with the kernel itself, I'm glad it was fixed. -- Dan Aloni [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
> Uh. It took couple of hours to find it. Just place
>
> { int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i < 6553600;
>i++) { *p; } }(**)
>
> instead of udelay(300) and this loop does not finish. Same for
> unsigned long* p. inb/outb(0x3C0) are ok. Writes are OK too. Only
> simple fetches from videoram kills it.
>
> When I replaced address with 0xC01B8000 (some cachable memory), it worked
> fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
> it is just set as cacheable in chipset), it works too.
Hmm, a read from an uncached location could result in sending delayed
APIC writes to the bus in case of an incorrect MTRR setting for the APIC
space. Could you please disable CONFIG_X86_GOOD_APIC? This will result
in using locked cycles for APIC writes, i.e. immediate bus accesses.
Please also check MTRR settings, especially for the APIC range. They
might need fixing.
> at the beginning of trampoline.S, and then boot with 'no-scroll', but
> character in upper left corner did not change, so secondary CPU probably
> even did not start code fetches. That's all I can say until
> I put non-AGP card into the box (but I need AGP, so it is not real
> option).
An easier way to check an application processor is alive could be
enabling the speaker -- after setting it up by the bootstrap CPU it only
takes three instructions to set bits 0 and 1 of port 0x61 and the result
is not volatile. A LED diagnostic display would be better, but typical
PCs don't have one, unfortunately.
> Yeah. Just do not read video memory when another CPU starts. I'll try
> disabling cache on both CPUs, maybe it will make some difference, as
> secondary CPU should start with caches disabled. But maybe that it is
> just broken AGP bus, and nothing else. But until I find what's really
> broken on my hardware, I'd like to leave 'udelay(300)' in.
If the problem is with write combining then disabling the cache won't
help, I'm afraid.
> (*) When I was calling directly
> vt_console_print(NULL, "Message1\n", 9);
> vt_console_print(NULL, "Message2\n", 9);
> instead of printk, I got
> Message1
> Messag<0x..><0x..><0x00><0x80><0x..><0x80><0x..><0x80>...
> - wrong text with wrong length, so it probably started fetching garbage
> instead of string as soon as second CPU started (no, it did not race due
> to missing console_lock; before first printk() secondary CPU should fill
> whole screen with letter '2'. It did not).
I would still verify (i.e. with the speaker) that's really the second CPU
causing the corruption.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
> > In the case where it boots does it also report mismatched MTRRs ?? > > Yes, it complains. But BIOS correctly reports x1/x2 depending on > number of CPUs I plug into motherboard, so I believe that it did > some initialization before it start loading OS. That may explain the hangs. Intel docs don't seem to guarantee what happens if the MTRRs don't match across CPU's. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote: > > Pardon me for not fully groking the issues here and possibly coming to a > wrong conclusion, but this has to do with SMP systems crashing at APIC > init time, just before penguin display (with fbcon at least)? If so, I > have a board that does this with certain cache settings made in the BIOS. > It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. I'm using BIOS dated 19/07/2000, last week it was latest BIOS on Gigabyte site for 6VXD7 (two PIII/800). I did not looked for updates today yet. I tried to change C2P Concurrency & Master (en/dis), AGP Mode (1x/2x/4x), Power mgmt - Display Activity (monitor/ignore), PNP OS (yes/no) (24 combinations total), but any combination dies if there are read accesses to videoram during startup. Today I finally digged out some old ISA VGA (Realtek), plugged it in and - it dies too. So it does not depend on bus type. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 23:51, Alan Cox wrote: > > Yeah. Just do not read video memory when another CPU starts. I'll try > > disabling cache on both CPUs, maybe it will make some difference, as > > secondary CPU should start with caches disabled. But maybe that it is > > just broken AGP bus, and nothing else. But until I find what's really > > broken on my hardware, I'd like to leave 'udelay(300)' in. > > In the case where it boots does it also report mismatched MTRRs ?? Yes, it complains. But BIOS correctly reports x1/x2 depending on number of CPUs I plug into motherboard, so I believe that it did some initialization before it start loading OS. calibrating APIC timer ... . CPU clock speed is 797.0452 MHz. . host bus clock speed is 99.6305 MHz. cpu: 0, clocks: 996305, slice: 332101 CPU0 cpu: 1, clocks: 996305, slice: 332101 CPU1 checking TSC synchronization across CPUs: passed. Setting commenced=1, go go go mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test13-pre3] rootfs (3rd attempt) (fwd)
Linus, please ignore this one _only_ if you have received this message
today already -- it is identical to previous one (resending only because
of email problems)
-- Forwarded message --
Date: Tue, 19 Dec 2000 09:25:08 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: [patch-2.4.0-test13-pre3] rootfs (3rd attempt)
Hi Linus,
The "final" version of yesterday contained two bugs (thanks to Andreas
Dilger for spotting both of them). This version contains 0 bugs and was
very thoroughly tested (including boundary conditions etc.). Basically, it
is absolutely final, really.
the bugs were a) n < 32 should be n <= sizeof(rootfs) and b) the diff
context of the old panic msg was missing (because I hand-edited the patch
instead of remaking it).
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Tue Dec 19 08:16:32 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n <= sizeof(rootfs))
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1593,7 +1621,8 @@
put_filesystem(fs_type);
}
read_unlock(_systems_lock);
- panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
+fail:
+ panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
+kdevname(ROOT_DEV));
mount_it:
printk ("VFS: Mounted root (%s filesystem)%s.\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test13-pre3] rootfs (3rd attempt) (fwd)
Linus, please ignore this one _only_ if you have received this message
today already -- it is identical to previous one (resending only because
of email problems)
-- Forwarded message --
Date: Tue, 19 Dec 2000 09:25:08 + (GMT)
From: Tigran Aivazian [EMAIL PROTECTED]
To: Linus Torvalds [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [patch-2.4.0-test13-pre3] rootfs (3rd attempt)
Hi Linus,
The "final" version of yesterday contained two bugs (thanks to Andreas
Dilger for spotting both of them). This version contains 0 bugs and was
very thoroughly tested (including boundary conditions etc.). Basically, it
is absolutely final, really.
the bugs were a) n 32 should be n = sizeof(rootfs) and b) the diff
context of the old panic msg was missing (because I hand-edited the patch
instead of remaking it).
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Tue Dec 19 08:16:32 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include linux/config.h
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n 1 n = sizeof(rootfs))
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type-next) {
if (!(fs_type-fs_flags FS_REQUIRES_DEV))
@@ -1593,7 +1621,8 @@
put_filesystem(fs_type);
}
read_unlock(file_systems_lock);
- panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
+fail:
+ panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
+kdevname(ROOT_DEV));
mount_it:
printk ("VFS: Mounted root (%s filesystem)%s.\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 23:51, Alan Cox wrote: Yeah. Just do not read video memory when another CPU starts. I'll try disabling cache on both CPUs, maybe it will make some difference, as secondary CPU should start with caches disabled. But maybe that it is just broken AGP bus, and nothing else. But until I find what's really broken on my hardware, I'd like to leave 'udelay(300)' in. In the case where it boots does it also report mismatched MTRRs ?? Yes, it complains. But BIOS correctly reports x1/x2 depending on number of CPUs I plug into motherboard, so I believe that it did some initialization before it start loading OS. calibrating APIC timer ... . CPU clock speed is 797.0452 MHz. . host bus clock speed is 99.6305 MHz. cpu: 0, clocks: 996305, slice: 332101 CPU0T0:996304,T1:664192,D:11,S:332101,C:996305 cpu: 1, clocks: 996305, slice: 332101 CPU1T0:996304,T1:332096,D:6,S:332101,C:996305 checking TSC synchronization across CPUs: passed. Setting commenced=1, go go go mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote: Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. I'm using BIOS dated 19/07/2000, last week it was latest BIOS on Gigabyte site for 6VXD7 (two PIII/800). I did not looked for updates today yet. I tried to change C2P Concurrency Master (en/dis), AGP Mode (1x/2x/4x), Power mgmt - Display Activity (monitor/ignore), PNP OS (yes/no) (24 combinations total), but any combination dies if there are read accesses to videoram during startup. Today I finally digged out some old ISA VGA (Realtek), plugged it in and - it dies too. So it does not depend on bus type. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
In the case where it boots does it also report mismatched MTRRs ?? Yes, it complains. But BIOS correctly reports x1/x2 depending on number of CPUs I plug into motherboard, so I believe that it did some initialization before it start loading OS. That may explain the hangs. Intel docs don't seem to guarantee what happens if the MTRRs don't match across CPU's. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote:
Uh. It took couple of hours to find it. Just place
{ int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i 6553600;
i++) { *p; } }(**)
instead of udelay(300) and this loop does not finish. Same for
unsigned long* p. inb/outb(0x3C0) are ok. Writes are OK too. Only
simple fetches from videoram kills it.
When I replaced address with 0xC01B8000 (some cachable memory), it worked
fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
it is just set as cacheable in chipset), it works too.
Hmm, a read from an uncached location could result in sending delayed
APIC writes to the bus in case of an incorrect MTRR setting for the APIC
space. Could you please disable CONFIG_X86_GOOD_APIC? This will result
in using locked cycles for APIC writes, i.e. immediate bus accesses.
Please also check MTRR settings, especially for the APIC range. They
might need fixing.
at the beginning of trampoline.S, and then boot with 'no-scroll', but
character in upper left corner did not change, so secondary CPU probably
even did not start code fetches. That's all I can say until
I put non-AGP card into the box (but I need AGP, so it is not real
option).
An easier way to check an application processor is alive could be
enabling the speaker -- after setting it up by the bootstrap CPU it only
takes three instructions to set bits 0 and 1 of port 0x61 and the result
is not volatile. A LED diagnostic display would be better, but typical
PCs don't have one, unfortunately.
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else. But until I find what's really
broken on my hardware, I'd like to leave 'udelay(300)' in.
If the problem is with write combining then disabling the cache won't
help, I'm afraid.
(*) When I was calling directly
vt_console_print(NULL, "Message1\n", 9);
vt_console_print(NULL, "Message2\n", 9);
instead of printk, I got
Message1
Messag0x..0x..0x000x800x..0x800x..0x80...
- wrong text with wrong length, so it probably started fetching garbage
instead of string as soon as second CPU started (no, it did not race due
to missing console_lock; before first printk() secondary CPU should fill
whole screen with letter '2'. It did not).
I would still verify (i.e. with the speaker) that's really the second CPU
causing the corruption.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
success with test13-pre3
I'm glad to report that 2.4.0-test13-pre3 fixes the lockup (and odd Oops messages) problems I had from test12 til test13-pre2. I've been running it on both of my computers for a day and a half and everything is OK. At first, we thought it had something to do with the modules I was using, but I was unable to confirm that, so I suspected it was something to do with the kernel itself, I'm glad it was fixed. -- Dan Aloni [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 19 Dec 00 at 19:30, Maciej W. Rozycki wrote: When I replaced address with 0xC01B8000 (some cachable memory), it worked fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe it is just set as cacheable in chipset), it works too. Hmm, a read from an uncached location could result in sending delayed APIC writes to the bus in case of an incorrect MTRR setting for the APIC space. Could you please disable CONFIG_X86_GOOD_APIC? This will result in using locked cycles for APIC writes, i.e. immediate bus accesses. I did... So it uses 'xchg %eax,APIC_ICR' instead of 'movl %eax,APIC_ICR', yes (as verified in generated code...)? No change, still dies, as expected (do not forget that before it dies, it can do ~0x1300 write-read cycles from videomemory (AGP4x), so secondary CPU just does some thinking before it kills machine; only problem is that 0x1300 wr-rd cycles to VGA apperture take 3.48ms, and this does not correspond with needed 200us udelay. Maybe chipset decides to do something when second CPU cannot obtain bus access in 10 pci cycles?). Please also check MTRR settings, especially for the APIC range. They might need fixing. Do you (or anyone else) have code which can dump MTRR registers of each of CPU before mtrr driver takes over them? At least first CPU does not have any problem... at the beginning of trampoline.S, and then boot with 'no-scroll', but character in upper left corner did not change, so secondary CPU probably even did not start code fetches. That's all I can say until I put non-AGP card into the box (but I need AGP, so it is not real option). An easier way to check an application processor is alive could be enabling the speaker -- after setting it up by the bootstrap CPU it only takes three instructions to set bits 0 and 1 of port 0x61 and the result is not volatile. A LED diagnostic display would be better, but typical PCs don't have one, unfortunately. Fortunately secondary CPU starts with AL 3 == 0, so it is just one 'outb %al,$0x61' instruction. When first CPU reads memory in loop, it beeps and beeps and beeps. If first CPU does 'udelay(300);', it works fine (I put mdelay(100) after enabling speaker, so I hear short 1000Hz beep during boot). So secondary CPU does not correctly execute even first instruction. But it either locks bus forever (looks like that because of ATX poweroff button does not work anymore), or confuses first CPU so much that it also cannot continue... Yeah. Just do not read video memory when another CPU starts. I'll try disabling cache on both CPUs, maybe it will make some difference, as secondary CPU should start with caches disabled. But maybe that it is just broken AGP bus, and nothing else. But until I find what's really broken on my hardware, I'd like to leave 'udelay(300)' in. If the problem is with write combining then disabling the cache won't help, I'm afraid. Read loop reads one short from one constant address, so any write* should not make any problem. instead of string as soon as second CPU started (no, it did not race due to missing console_lock; before first printk() secondary CPU should fill whole screen with letter '2'. It did not). ^ digit. I'm sorry ;-) I would still verify (i.e. with the speaker) that's really the second CPU causing the corruption. I even placed 'wbinvd' and 'wbinvd; cpuid' before sending startup IPI, but it does not matter. Secondary CPU just does not finish even first instruction when first CPU reads from videoram again and again. Without VIA datasheet I cannot try to disable some PCI features to find which one is culprit, so I'm sorry. Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000, Petr Vandrovec wrote: On 18 Dec 00 at 21:59, [EMAIL PROTECTED] wrote: Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. I'm using BIOS dated 19/07/2000, last week it was latest BIOS on Gigabyte site for 6VXD7 (two PIII/800). I did not looked for updates today yet. I tried to change C2P Concurrency Master (en/dis), AGP Mode (1x/2x/4x), Power mgmt - Display Activity (monitor/ignore), PNP OS (yes/no) (24 combinations total), but any combination dies if there are read accesses to videoram during startup. Today I finally digged out some old ISA VGA (Realtek), plugged it in and - it dies too. So it does not depend on bus type. Okay. Mine, as far as I can tell, only depends on the L2 cache being set to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS for this motherboard available. It's a TD5TH version 1.1 H. Have you tried booting with an hercmono (if you can get your paws on one, that is)?. Right after 'Freeing unused kernel memory...' I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 without fbcon. With fbcon it would appear to switch video mode and freeze with a black screen with cursor at the bottom, at that point. And then I get an oops dump in the swapper task. I'll try decoding it in a little while, since I'll have to manually input it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ PATCH ] against 2.4.0-test13-pre3 - fixes builds for ALPHA
Hmm. Gotta build setup-*.c somehow. Alpha Config defines ALPHA_FOO (Generic or specific model #) but not vanilla alpha. --- linux.orig/arch/alpha/config.in Tue Dec 19 14:54:14 2000 +++ linux/arch/alpha/config.in Tue Dec 19 14:53:05 2000 @@ -4,6 +4,7 @@ # define_bool CONFIG_UID16 n +define_bool CONFIG_ALPHA y mainmenu_name "Kernel configuration of Linux for Alpha machines" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Tue, 19 Dec 2000 [EMAIL PROTECTED] wrote: [snip of Petr's system info] Okay. Mine, as far as I can tell, only depends on the L2 cache being set to '64MB' instead of '512MB' in the field 'L2 Cache Cacheable Size' under 'Chipset Features Setup' on my BIOS. This is unfortunately the latest BIOS for this motherboard available. It's a TD5TH version 1.1 H. Have you tried booting with an hercmono (if you can get your paws on one, that is)?. Right after 'Freeing unused kernel memory...' I get a kernel BUG at buffer.c:821 with this setting at 256MB, -test12 without fbcon. With fbcon it would appear to switch video mode and freeze with a black screen with cursor at the bottom, at that point. And then I get an oops dump in the swapper task. I'll try decoding it in a little while, since I'll have to manually input it. Here we go: I DID have to copy it onto paper and type it in after rebooting. EIP; c01354a6 end_buffer_io_async+ea/12c = Trace; c0217d72 tvecs+3a1e/b81c Trace; c02180da tvecs+3d86/b81c Trace; c0186e85 end_that_request_first+65/c0 Trace; c019e238 ide_end_request+34/88 Trace; c01a22b7 read_intr+e7/120 Trace; c019fb0e ide_intr+12a/194 Trace; c01a21d0 read_intr+0/120 Trace; c010c2d1 handle_IRQ_event+59/84 Trace; c010c4b8 do_IRQ+a8/fc Trace; c0108d40 default_idle+0/34 Trace; c010ac00 ret_from_intr+0/20 Trace; c0108d40 default_idle+0/34 Trace; c0108dbc cpu_idle+28/54 Trace; c0108dd2 cpu_idle+3e/54 Trace; c0105000 empty_bad_page+0/1000 Trace; c01001cf L6+0/2 Code; c01354a6 end_buffer_io_async+ea/12c _EIP: Code; c01354a6 end_buffer_io_async+ea/12c = 0: 0f 0b ud2a = Code; c01354a8 end_buffer_io_async+ec/12c 2: 83 c4 0c add$0xc,%esp Code; c01354ab end_buffer_io_async+ef/12c 5: 90nop Code; c01354ac end_buffer_io_async+f0/12c 6: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c01354b0 end_buffer_io_async+f4/12c a: 8d 5e 28 lea0x28(%esi),%ebx Code; c01354b3 end_buffer_io_async+f7/12c d: 8d 46 2c lea0x2c(%esi),%eax Code; c01354b6 end_buffer_io_async+fa/12c 10: 39 46 2c cmp%eax,0x2c(%esi) Code; c01354b9 end_buffer_io_async+fd/12c 13: 74 00 je 15 _EIP+0x15 c01354bb end_buffer_io_async+ff/12c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
The saga continues into test13-pre3-ac3: (last good tdfx.o was from test12) # uname -a Linux jyro.mirai.cx 2.4.0-test13pre3-ac3 #1 Tue Dec 19 21:26:36 PST 2000 i586 unknown # lsmod Module Size Used by iptable_filter 1872 0 (autoclean) (unused) ip_nat_ftp 3424 0 (unused) iptable_nat12672 1 [ip_nat_ftp] ip_conntrack_ftp2048 0 (unused) ip_conntrack 13056 2 [ip_nat_ftp iptable_nat ip_conntrack_ftp] ip_tables 10624 4 [iptable_filter iptable_nat] ide-scsi8096 0 8139too15024 2 (autoclean) emu10k145248 0 # modprobe tdfx /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol remap_page_range /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __wake_up /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol mtrr_add /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __generic_copy_from_user /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol schedule /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol kmalloc /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol si_meminfo /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol create_proc_entry /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol inter_module_put /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __get_free_pages /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol boot_cpu_data /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol inter_module_get /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol remove_wait_queue /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol high_memory /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol iounmap /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol free_pages /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __ioremap /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol del_timer /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol interruptible_sleep_on /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __pollwait /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol kfree /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol remove_proc_entry /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol pci_find_slot /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol kill_fasync /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol fasync_helper /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol add_wait_queue /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol do_mmap_pgoff /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol mem_map /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol sprintf /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol jiffies /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol printk /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol add_timer /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: unresolved sym bol __generic_copy_to_user /lib/modules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o: insmod /lib/mo dules/2.4.0-test13pre3-ac3/kernel/drivers/char/drm/tdfx.o failed Hope this helps - jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. -- Ferret - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
> List: linux-kernel > Subject: Re: test13-pre3 woes > From: Peter Samuelson <[EMAIL PROTECTED]> > Date: 2000-12-18 9:19:13 > [Download message RAW] > > > [J Sloan] > > The module now compiles and gets installed - > > Unfortunately, attempting to load it does not go well: > > > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range > > kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up > > kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add > > kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user > > kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule > > kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc > > kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo > > Those symbols are rather generic and rather important. Sounds like a > generic module problem. Do other modules load? Does your kernel use > MODVERSIONS? (This module apparently doesn't.) Are you using a recent > version of modutils? > > Puzzled. Maybe Keith Owens knows something. > > Peter I got this, too. The one liner send here on lkm seems to be not enough. Even Alan's ac1/2 did not do the trick. The 'new' Linux makefile changes brake this stuff. It works before these changes. So Rik any comments? Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
Olaf Titz wrote: > In article <[EMAIL PROTECTED]> you write: > > [J Sloan] > > > > > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range > >... > > Those symbols are rather generic and rather important. Sounds like a > > generic module problem. Do other modules load? Yes, rtl8139, emu10k are loaded and working fine. > Does your kernel use > > MODVERSIONS? Yes, I have CONFIG_MODVERSIONS=y > (This module apparently doesn't.) Are you using a recent > > version of modutils? # insmod -V insmod version 2.3.21 ... > The most important question: Did you run "make dep" after doing the patch? Yes, after the patch, it was, as always: make clean make menuconfig make dep bzlilo modules modules_install Same problem with 2.4.0-test13-pre3-ac1 on my Linux workstation at the office, where the token ring driver fails as well (olympic.o) BTW, in my experience to date with kernels from 2.3.36 up to 2.4.0-test-12 it has all worked well. jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
> Yeah. Just do not read video memory when another CPU starts. I'll try > disabling cache on both CPUs, maybe it will make some difference, as > secondary CPU should start with caches disabled. But maybe that it is > just broken AGP bus, and nothing else. But until I find what's really > broken on my hardware, I'd like to leave 'udelay(300)' in. In the case where it boots does it also report mismatched MTRRs ?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 19:44, Maciej W. Rozycki wrote:
> > No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or
> > PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA...
>
> Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try
> if accessing one bus or another changes the behaviour.
Uh. It took couple of hours to find it. Just place
{ int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i < 6553600;
i++) { *p; } }(**)
instead of udelay(300) and this loop does not finish. Same for
unsigned long* p. inb/outb(0x3C0) are ok. Writes are OK too. Only
simple fetches from videoram kills it.
When I replaced address with 0xC01B8000 (some cachable memory), it worked
fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
it is just set as cacheable in chipset), it works too.
Symptoms of lockup are same as hangup in printk() without udelay(300), only
problem is that 'vt_console_print' (*) does not do fetches from videoram, it
does stores only...
Placing this loop before sending startup IPI, or just below udelay(300)
is OK (modulo that this loop takes so long that secondary CPU complains
about no callin received).
I even tried to add:
mov $0xB800,%ax
mov %ax,%ds
movw %ax,0
at the beginning of trampoline.S, and then boot with 'no-scroll', but
character in upper left corner did not change, so secondary CPU probably
even did not start code fetches. That's all I can say until
I put non-AGP card into the box (but I need AGP, so it is not real option).
> > and VT82C686 (rev 22) ISA bridge. I tried to request documentation
> > of 694X from VIA, but I did not heard from them. They have probably
> > some secrets hidden in their hardware...
>
> They wan't to keep the competition from being bug-compatible, it would
> seem...
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else. But until I find what's really
broken on my hardware, I'd like to leave 'udelay(300)' in.
(*) When I was calling directly
vt_console_print(NULL, "Message1\n", 9);
vt_console_print(NULL, "Message2\n", 9);
instead of printk, I got
Message1
Messag<0x..><0x..><0x00><0x80><0x..><0x80><0x..><0x80>...
- wrong text with wrong length, so it probably started fetching garbage
instead of string as soon as second CPU started (no, it did not race due
to missing console_lock; before first printk() secondary CPU should fill
whole screen with letter '2'. It did not).
(**) When I had '*p = i; *p' in loop, from visual inspection it was
dying in range i=0x1380-0x13FF (blue background, cyan letter with diacritics).
End of guessing.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test13-pre3 m68k Makefiles
This patch updates the Makefiles used by Linux/m68k to the new Makefile syntax. Additionally I fixed a bug in arch/ppc/amiga/Makefile (for APUS). --- linux-2.4.0-test13-pre3/MakefileMon Dec 18 12:34:22 2000 +++ linux-m68k-test13-pre3/Makefile Mon Dec 18 12:40:50 2000 @@ -159,7 +159,7 @@ DRIVERS-$(CONFIG_PCMCIA_CHRDEV) += drivers/char/pcmcia/pcmcia_char.o DRIVERS-$(CONFIG_DIO) += drivers/dio/dio.a DRIVERS-$(CONFIG_SBUS) += drivers/sbus/sbus_all.o -DRIVERS-$(CONFIG_ZORRO) += drivers/zorro/zorro.a +DRIVERS-$(CONFIG_ZORRO) += drivers/zorro/driver.o DRIVERS-$(CONFIG_FC4) += drivers/fc4/fc4.a DRIVERS-$(CONFIG_ALL_PPC) += drivers/macintosh/macintosh.o DRIVERS-$(CONFIG_MAC) += drivers/macintosh/macintosh.o --- linux-2.4.0-test13-pre3/arch/m68k/amiga/MakefileThu Jul 30 20:08:19 1998 +++ linux-m68k-test13-pre3/arch/m68k/amiga/Makefile Mon Dec 18 12:53:58 2000 @@ -8,11 +8,11 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := amiga.o -O_OBJS := config.o amiints.o cia.o chipram.o amisound.o -OX_OBJS := amiga_ksyms.o -ifdef CONFIG_AMIGA_PCMCIA -O_OBJS := $(O_OBJS) pcmcia.o -endif +export-objs:= amiga_ksyms.o + +obj-y := config.o amiints.o cia.o chipram.o amisound.o amiga_ksyms.o + +obj-$(CONFIG_AMIGA_PCMCIA) += pcmcia.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/apollo/Makefile Tue Feb 8 11:04:33 2000 +++ linux-m68k-test13-pre3/arch/m68k/apollo/MakefileMon Dec 18 12:57:03 2000 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := apollo.o -O_OBJS := config.o dn_ints.o dma.o \ +obj-y := config.o dn_ints.o dma.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/atari/MakefileTue Feb 8 11:04:33 2000 +++ linux-m68k-test13-pre3/arch/m68k/atari/Makefile Mon Dec 18 12:54:27 2000 @@ -8,14 +8,14 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := atari.o -O_OBJS := config.o time.o debug.o atakeyb.o ataints.o stdma.o atasound.o \ -joystick.o stram.o -OX_OBJS := atari_ksyms.o + +export-objs:= atari_ksyms.o + +obj-y := config.o time.o debug.o atakeyb.o ataints.o stdma.o \ + atasound.o joystick.o stram.o atari_ksyms.o ifdef CONFIG_PCI -ifdef CONFIG_HADES -O_OBJS += hades-pci.o -endif +obj-$(CONFIG_HADES)+= hades-pci.o endif include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/bvme6000/Makefile Sat Jun 13 22:14:31 1998 +++ linux-m68k-test13-pre3/arch/m68k/bvme6000/Makefile Mon Dec 18 12:54:32 2000 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := bvme6000.o -O_OBJS := config.o bvmeints.o rtc.o -#OX_OBJS = ksyms.o + +obj-y := config.o bvmeints.o rtc.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/hp300/MakefileWed Sep 2 18:39:18 1998 +++ linux-m68k-test13-pre3/arch/m68k/hp300/Makefile Mon Dec 18 12:54:43 2000 @@ -8,10 +8,11 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := hp300.o -O_OBJS := ksyms.o config.o ints.o time.o reboot.o -ifdef CONFIG_VT -O_OBJS += hil.o -endif +export-objs:= ksyms.o + +obj-y := ksyms.o config.o ints.o time.o reboot.o + +obj-$(CONFIG_VT) += hil.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/kernel/Makefile Thu Apr 13 21:17:11 2000 +++ linux-m68k-test13-pre3/arch/m68k/kernel/MakefileMon Dec 18 12:54:58 2000 @@ -17,13 +17,13 @@ endif O_TARGET := kernel.o -O_OBJS := entry.o process.o traps.o ints.o signal.o ptrace.o \ - sys_m68k.o time.o semaphore.o -OX_OBJS := setup.o m68k_ksyms.o -ifdef CONFIG_PCI -O_OBJS += bios32.o -endif +export-objs:= setup.o m68k_ksyms.o + +obj-y := entry.o process.o traps.o ints.o signal.o ptrace.o \ + sys_m68k.o time.o semaphore.o setup.o m68k_ksyms.o + +obj-$(CONFIG_PCI) += bios32.o head.o: head.S m68k_defs.h --- linux-2.4.0-test13-pre3/arch/m68k/lib/Makefile Thu Dec 14 12:14:15 2000 +++ linux-m68k-test13-pre3/arch/m68k/lib/Makefile Mon Dec 18 12:55:09 2000 @@ -6,6 +6,8 @@ $(CC) $(AFLAGS) -traditional -c $< -o $@ L_TARGET = lib.a -L_OBJS = ashrdi3.o lshrdi3.o checksum.o memcpy.o memcmp.o memset.o semaphore.o muldi3.o + +obj-y := ashrdi3.o lshrdi3.o checksum.o memcpy.o memcmp.o memset.o \ + semaphore.o muldi3.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/mac/Makefile Tue Feb 15 21:49:28 2000 +++ linux-m68k-test13-pre3/arch/m68k/mac/Makefile Mon Dec 18 12:55:22 2000 @@ -8,8 +8,10 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := mac.o -OX_OBJS := mac_ksyms.o -O_OBJS := config.o bootparse.o macints.o iop.o via.o oss.o psc.o \ - baboon.o macboing.o debug.o misc.o + +export-objs:= mac_ksyms.o + +ob
Re: test13-pre3
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
> The appended patch fixes the following:
>
> 1) We cannot unlock the page in shmem_writepage on ooswap since
>page_launder will do this later.
>
> 2) We should set the inode number of SYSV segments to the (user)
>shmid and not the internal id.
And here additionally is the SYSV detach/destroy logic fixed which
(again) left destroyed shm segments hang around :-(
I also cleaned up the list of included files in ipc/shm.c
Greetings
Christoph
diff -uNr 4-13-3/ipc/shm.c c/ipc/shm.c
--- 4-13-3/ipc/shm.cMon Dec 18 15:08:32 2000
+++ c/ipc/shm.c Mon Dec 18 20:07:21 2000
@@ -15,23 +15,13 @@
*
*/
-#include
-#include
#include
#include
-#include
-#include
#include
-#include
#include
#include
-#include
-#include
#include
-#include
-
#include
-#include
#include "util.h"
@@ -109,6 +99,7 @@
BUG();
shp->shm_atim = CURRENT_TIME;
shp->shm_lprid = current->pid;
+ shp->shm_nattch++;
shm_unlock(id);
}
@@ -123,21 +114,14 @@
*
* @shp: struct to free
*
- * It has to be called with shp and shm_ids.sem locked and will
- * release them
+ * It has to be called with shp and shm_ids.sem locked
*/
static void shm_destroy (struct shmid_kernel *shp)
{
- struct file * file = shp->shm_file;
-
- shp->shm_file = NULL;
shm_tot -= (shp->shm_segsz + PAGE_SIZE - 1) >> PAGE_SHIFT;
- shm_unlock (shp->id);
shm_rmid (shp->id);
+ fput (shp->shm_file);
kfree (shp);
- up (_ids.sem);
- /* put the file outside the critical path to prevent recursion */
- fput (file);
}
/*
@@ -158,10 +142,10 @@
BUG();
shp->shm_lprid = current->pid;
shp->shm_dtim = CURRENT_TIME;
- if(shp->shm_flags & SHM_DEST &&
- file_count (file) == 2) /* shp and the vma have the last
- references*/
- return shm_destroy (shp);
+ shp->shm_nattch--;
+ if(shp->shm_nattch == 0 &&
+ shp->shm_flags & SHM_DEST)
+ shm_destroy (shp);
shm_unlock(id);
up (_ids.sem);
@@ -176,7 +160,7 @@
}
static struct file_operations shm_file_operations = {
- mmap: shm_mmap
+ mmap: shm_mmap
};
static struct vm_operations_struct shm_vm_ops = {
@@ -218,9 +202,10 @@
shp->shm_atim = shp->shm_dtim = 0;
shp->shm_ctim = CURRENT_TIME;
shp->shm_segsz = size;
+ shp->shm_nattch = 0;
shp->id = shm_buildid(id,shp->shm_perm.seq);
shp->shm_file = file;
- file->f_dentry->d_inode->i_ino = id;
+ file->f_dentry->d_inode->i_ino = shp->id;
file->f_op = _file_operations;
shm_tot += numpages;
shm_unlock (id);
@@ -370,15 +355,13 @@
struct inode * inode;
shp = shm_get(i);
- if(shp == NULL || shp->shm_file == NULL)
+ if(shp == NULL)
continue;
inode = shp->shm_file->f_dentry->d_inode;
- down (>i_sem);
- *rss += inode->i_mapping->nrpages;
spin_lock (>u.shmem_i.lock);
+ *rss += inode->i_mapping->nrpages;
*swp += inode->u.shmem_i.swapped;
spin_unlock (>u.shmem_i.lock);
- up (>i_sem);
}
}
@@ -462,7 +445,7 @@
tbuf.shm_ctime = shp->shm_ctim;
tbuf.shm_cpid = shp->shm_cprid;
tbuf.shm_lpid = shp->shm_lprid;
- tbuf.shm_nattch = file_count (shp->shm_file) - 1;
+ tbuf.shm_nattch = shp->shm_nattch;
shm_unlock(shmid);
if(copy_shmid_to_user (buf, , version))
return -EFAULT;
@@ -512,13 +495,12 @@
goto out_up;
err = shm_checkid(shp, shmid);
if (err == 0) {
- if (file_count (shp->shm_file) == 1) {
+ if (shp->shm_nattch){
+ shp->shm_flags |= SHM_DEST;
+ /* Do not find it any more */
+ shp->shm_perm.key = IPC_PRIVATE;
+ } else
shm_destroy (shp);
- return 0;
- }
- shp->shm_flags |= SHM_DEST;
- /* Do not find it any more */
- shp->shm_perm.key = IPC_PRIVATE;
}
/* Unlock */
shm_unlock(shmid);
@@ -619,13 +601,23 @@
return -EACCES;
}
file = shp->shm_file;
- get_file (file);
+ shp->shm_nattch++;
shm_unlock(shmid);
down(>mm->mmap_sem);
user_addr = (void *) do_mmap (file, addr, file->f_dentry->d_inode->i_size,
prot, flags, 0);
Re: Startup IPI (was: Re: test13-pre3)
On Mon, 18 Dec 2000, Petr Vandrovec wrote: > It is possible. But it is hard to track, as it works with serial console, > and it is not possible to paint characters to VGA screen, as vgacon uses > hardware panning instead of scrolling :-( And if it dies, shift-pageup > apparently does not work... And filling whole 32KB with some char > does not work, as it changes timing too much... Just disable the problematic printk()s for making tests (you may just undefine APIC_DEBUG in include/asm-i386/apic.h) -- we already know what is going to be printed here. ;-) > No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or > PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA... Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try if accessing one bus or another changes the behaviour. > Yes. I could understand if I had to place bigger udelay() after INIT IPI, > as this can cause some specific PIII initialization and Intel says that > there should not be any MESI traffic during this init (at least I understand Hmm, weird -- for integrated APICs an INIT IPI is about the same as shutdown apart from the fact an NMI won't wake up a CPU (that might actually be the local APIC not passing NMIs to the CPU in this case, though). > it that way). But after startup IPI it should just start executing code... > I tried to put 'wbinvd' here and there, but it did not make any change, > only udelay() between startup IPI cmd and first printk() did. Hmm, a startup IPI is rather fast so the code just after issuing it may somehow interact with the application's CPU trampoline. But try to disable CONFIG_X86_GOOD_APIC, yet (you may configure for classic Pentium, for example), and see if that changes anything (it shouldn't, but who knows...). > I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge, Just look at the board and search for an I/O APIC chip. ;-) > and VT82C686 (rev 22) ISA bridge. I tried to request documentation > of 694X from VIA, but I did not heard from them. They have probably > some secrets hidden in their hardware... They wan't to keep the competition from being bug-compatible, it would seem... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[final] Re: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
On Mon, 18 Dec 2000, Andreas Dilger wrote:
> If I could add one thing here (we have had a 2.2 patch like this for testing
> with ext3) - if you specify the rootfstype parameter don't use the "quiet"
> option to read_super, so you know why it couldn't mount a specific filesystem
> as root, and/or print rootfs type in the panic message.
Agree completely.
Here is the hopefully final version. Sorry, Linus, I thought the first
version was final :) Looks like I have missed a couple of very useful
things... Thanks to all who commented!
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 15:03:44 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n < 32)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,0);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1593,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(_systems_lock);
+fail:
panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
Tigran, you write:
> Thanks to suggestions from Andries and Peter I enhanced the rootfs patch
> to do the same it did before + panic when rootfs= is given but failed to
If I could add one thing here (we have had a 2.2 patch like this for testing
with ext3) - if you specify the rootfstype parameter don't use the "quiet"
option to read_super, so you know why it couldn't mount a specific filesystem
as root, and/or print rootfs type in the panic message.
This is especially useful if you have something in LILO that you forgot about...
Cheers, Andreas
=
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 14:49:08 2000
@@ -1600,7 +1600,7 @@
if (*rootfs) {
fs_type = get_fs_type(rootfs);
if (fs_type) {
- sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,0);
if (sb)
goto mount_it;
}
@@ -1622,7 +1622,8 @@
}
read_unlock(_systems_lock);
fail:
- panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
+ panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
+ kdevname(ROOT_DEV));
mount_it:
printk ("VFS: Mounted root (%s filesystem)%s.\n",
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 18:18, Maciej W. Rozycki wrote: > On Mon, 18 Dec 2000, Petr Vandrovec wrote: > > > No. Without udelay() before first printk() it just does not boot on my > > motherboard. There were two choices: either remove all printk() from > > these loops (define Dprintk to null), or add udelay(x), where x >= 200, > > before first printk. I sent patch twice to linux-kernel, and to > > [EMAIL PROTECTED], and nobody said anything against it. > > I see. But are you sure this is the right fix? You may be covering > the real problem with this arbitrary delay. It is possible. But it is hard to track, as it works with serial console, and it is not possible to paint characters to VGA screen, as vgacon uses hardware panning instead of scrolling :-( And if it dies, shift-pageup apparently does not work... And filling whole 32KB with some char does not work, as it changes timing too much... > > analyzer (or if I should come with motherboard), I'm willing to continue > > testing. But current idea is that inb/outb done by cursor positioning > > code is incompatible with something else done in secondary CPU startup. > > Have you tried putting explicit display adapter (other ISA) I/O accesses > after sending the IPI to see if they trigger the problem? IPIs are No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA... > > Without delay() both CPU die, and board does not react to anything except > > hard reset anymore (and sometime it does not react even to hard reset; lookup > > for my messages during last week). > > Now THAT is weird. It might mean a chipset bug. Still no idea how an > inter-APIC message might trigger it -- it completely bypasses MB Yes. I could understand if I had to place bigger udelay() after INIT IPI, as this can cause some specific PIII initialization and Intel says that there should not be any MESI traffic during this init (at least I understand it that way). But after startup IPI it should just start executing code... I tried to put 'wbinvd' here and there, but it did not make any change, only udelay() between startup IPI cmd and first printk() did. > chipset... Hmm, maybe not... Is your I/O APIC discrete (like Intel's > 82093AA) or integrated? It appears there are vendors manufacturing I/O > APIC clones and this may imply new problems, sigh... I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge, and VT82C686 (rev 22) ISA bridge. I tried to request documentation of 694X from VIA, but I did not heard from them. They have probably some secrets hidden in their hardware... Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
On Mon, 18 Dec 2000, Petr Vandrovec wrote: > No. Without udelay() before first printk() it just does not boot on my > motherboard. There were two choices: either remove all printk() from > these loops (define Dprintk to null), or add udelay(x), where x >= 200, > before first printk. I sent patch twice to linux-kernel, and to > [EMAIL PROTECTED], and nobody said anything against it. I see. But are you sure this is the right fix? You may be covering the real problem with this arbitrary delay. I haven't actually noticed any of your previous mails -- given the load on the list I sometimes miss letters with "uninteresting" subjects. > No. If there is no udelay() before first printk(), on my GA-6VXD7 board > (SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting > for send to finish...'. So maybe we do not need udelay(200) below loop, > but for sure we need udelay() before first printk(). (my board works > without ANY udelay() in smpboot.c, except one I added... This one is > required.) If somebody lives in Prague, and wants to come with logical Other delays are imposed by the MPS (most if not all of them). For example there are systems that assert RESET to a CPU as a result of an INIT IPI. These systems need these delays to allow CPUs to recover. > analyzer (or if I should come with motherboard), I'm willing to continue > testing. But current idea is that inb/outb done by cursor positioning > code is incompatible with something else done in secondary CPU startup. Have you tried putting explicit display adapter (other ISA) I/O accesses after sending the IPI to see if they trigger the problem? IPIs are transmitted over the inter-APIC bus and should be completely invisible to other parts of the system. But the code involved in processing a printk() may interact with the one executed by another CPU right after waking it up. It would be worth to investigate it... > (it boots also without any kernel change with 'console=ttyS0,9600', but > it may be caused by slow serial line) Or by running different code. > Without delay() both CPU die, and board does not react to anything except > hard reset anymore (and sometime it does not react even to hard reset; lookup > for my messages during last week). Now THAT is weird. It might mean a chipset bug. Still no idea how an inter-APIC message might trigger it -- it completely bypasses MB chipset... Hmm, maybe not... Is your I/O APIC discrete (like Intel's 82093AA) or integrated? It appears there are vendors manufacturing I/O APIC clones and this may imply new problems, sigh... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
On 18 Dec 00 at 13:58, Maciej W. Rozycki wrote:
> What is this change about?
>
> diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c
>linux/arch/i386/kernel/smpboot.c
> --- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
> +++ linux/arch/i386/kernel/smpboot.cThu Dec 14 14:54:40 2000
> @@ -694,6 +694,11 @@
> apic_write_around(APIC_ICR, APIC_DM_STARTUP
> | (start_eip >> 12));
>
> + /*
> +* Give the other CPU some time to accept the IPI.
> +*/
> + udelay(300);
> +
> Dprintk("Startup point 1.\n");
>
> Dprintk("Waiting for send to finish...\n");
>
> There is the following code is just after it, making the above change
> just useless garbage:
No. Without udelay() before first printk() it just does not boot on my
motherboard. There were two choices: either remove all printk() from
these loops (define Dprintk to null), or add udelay(x), where x >= 200,
before first printk. I sent patch twice to linux-kernel, and to
[EMAIL PROTECTED], and nobody said anything against it.
> timeout = 0;
> do {
> Dprintk("+");
> udelay(100);
> send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
> } while (send_status && (timeout++ < 1000));
>
> /*
> * Give the other CPU some time to accept the IPI.
> */
> udelay(200);
>
> If we need 600usecs of delay for certain systems, then why not just make
> it like below?
No. If there is no udelay() before first printk(), on my GA-6VXD7 board
(SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting
for send to finish...'. So maybe we do not need udelay(200) below loop,
but for sure we need udelay() before first printk(). (my board works
without ANY udelay() in smpboot.c, except one I added... This one is
required.) If somebody lives in Prague, and wants to come with logical
analyzer (or if I should come with motherboard), I'm willing to continue
testing. But current idea is that inb/outb done by cursor positioning
code is incompatible with something else done in secondary CPU startup.
(it boots also without any kernel change with 'console=ttyS0,9600', but
it may be caused by slow serial line)
Without delay() both CPU die, and board does not react to anything except
hard reset anymore (and sometime it does not react even to hard reset; lookup
for my messages during last week).
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Oops Re: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
just a typo in the comment, sorry. Corrected version below.
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 15:03:44 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n < 32)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1593,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(_systems_lock);
+fail:
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test13-pre3] rootfs (2nd attempt)
Hi Linus,
Thanks to suggestions from Andries and Peter I enhanced the rootfs patch
to do the same it did before + panic when rootfs= is given but failed to
match the userspace mount(8) behaviour. Also other cleanups mentioned in
the thread are all incorporated (well, at least the sensible ones). Now,
everyone is (hopefully) happy.
Tested under 2.4.0-test13-pre3.
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 14:49:08 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will go through all registered filesystems.
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n < 32)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
@@ -1593,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(_systems_lock);
+fail:
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
Ok, the version below doesn't look too bad, except a couple things, see
below:
On Mon, 18 Dec 2000, Peter Samuelson wrote:
> -__setup("rootfs=", rootfs_setup);
> +__setup("rootfstype=", rootfs_setup);
this is wrong. If the parameter is "rootfstype" then the function is
rootfstype_setup(). Too long. No, "rootfs" was a good idea to beging with
(ask any kernel hacker who wrote UW7 BCP support -- they knew what they
were calling their variables :)
> {
> - struct file_system_type * fs_type;
> + struct file_system_type * fs_type = NULL;
this is not needed. Why did you put it there?
> + if (*rootfstype) {
> + fs_type = get_fs_type(rootfstype);
> + if (fs_type) {
> + sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
> + if (sb)
> + goto mount_it;
> + }
> + /* do NOT try all filesystems - user explicitly wanted this one */
> + goto fail;
> ...
> +fail:
> panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
we should also print out the filesystem type, so instead of having a fail
label I would put the panic() inside the code above.
I will redo the patch with your and Andries' comments in place and re-send
to Linus. Namely, the useful things, imho, from your suggestions are:
a) the space allocated for it should be 32 bytes and not 128
b) we should check if user passed any value and only then activate the
code
c) default value "" is ok (ok, fine, the extra line of code to check for
it is not too bad).
d) but the variable should still be called "rootfs" and not
"rootfstype". rootfstype is too long, too confusing and not
obvious. Whilst "rootfs" immediately tells you "it's the name of the
filesystem in the namespace defined by file_system_type->name"
Oh, btw you changed one place from 128 to 32 but forgot another -- never
mind :)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000, Peter Samuelson wrote:
>
> [Tigran Aivazian]
> > no, because it would cause a "spurious" call to get_fs_type("") which
> > we don't want to happen (by default i.e. -- if user _really_ wants it
> > that is ok). The default of "ext2" is fine.
>
> I still disagree -- super.c is no place to dictate the default root
> filesystem. And I agree with Andries that 'rootfs=' is confusing.
I have already covered both of these issues in the email I sent ages
ago... Here it is below (instead of re-sending) (the original got lost
because of the mail-abuse vs btconnect's randomness)
>From [EMAIL PROTECTED] Mon Dec 18 15:20:08 2000
Date: Mon, 18 Dec 2000 14:44:32 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000 [EMAIL PROTECTED] wrote:
> (i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
> It gives some property of the root filesystem, but which?
No, it is not ambiguous. Because, look at this sequence:
"ffs", "ufs", "bfs", "reiserfs", "vxfs", "sockfs", "pipefs", "nfs", ...
they are familiar to everyone and everyone immediately recognizes the
attribute they describe by the ending "fs". So, the attribute is
immediately obvious and should be recognized by programmer without need to
explicitly comment about it (it just is like it is _obvious_ that static
int x; is initialized to 0 and there is no need to start asking oneself
"what is this attribute of x that is being set to 0 here... ah.. it's the
_value_ thereof!" )
> +static char rootfs[128] __initdata = "ext2";
>
> (ii) It is a bad idea to arbitrarily select "ext2".
No, how could you say it is a bad idea without saying also _what_ is a
good idea? If there is no replacement for a bad idea then it is, by
definition, a good (or best) idea. So, having not found a better initial
value for rootfs[] I set it to "ext2". Setting it to "" is no good as I
explained to Peter. Setting it to NULL is also no good because needs an
extra line of code in mount_root() to check for it. So, what then? I say
"ext2" as it is the most popular Linux filesystem at the moment.
> (iii) I probably give the rootfstype explicitly because bad things
> (like disk corruption) happen when the kernel misrecognizes some
> filesystem, and perhaps starts updating access times or so.
> Thus, if the boot option rootfstype is given, I prefer a boot failure
> over a kernel attempt to try all filesystems it knows about, just like
> mount(8) only will start guessing when no explicit type was given.
that gives it a different semantics, i.e. you are changing the rules. I am
not sure which rules are better but there are advantages to it being as
is, e.g. one could hardcode "rootfs=vxfs" in their lilo.conf and rely on
fallback to ext2 for some of the partitions but not others.
This one is a matter of taste and if Linus says your way is better I will
redo the patch immediately. Both ways are fine with me.
Regards,
Tigran
>From [EMAIL PROTECTED] Mon Dec 18 15:20:13 2000
Date: Mon, 18 Dec 2000 14:54:40 + (GMT)
From: Tigran Aivazian <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000, Tigran Aivazian wrote:
> Setting it to NULL is also no good because needs an
> extra line of code in mount_root() to check for it.
before N people misunderstand the above -- I meant having just a
pointer and doing kmalloc/kfree manually.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
[Andries Brouwer]
> (i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
> It gives some property of the root filesystem, but which?
> (ii) It is a bad idea to arbitrarily select "ext2".
> (iii) [...] Thus, if the boot option rootfstype is given, I prefer a
> boot failure over a kernel attempt to try all filesystems it knows
Agreed on all counts.
Peter
--- test13pre3+rootfs/fs/super.c~ Mon Dec 18 09:06:47 2000
+++ test13pre3+rootfs/fs/super.cMon Dec 18 09:18:02 2000
@@ -18,7 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
- * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
+ * Added rootfstype boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -59,11 +59,11 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
-/* this can be set at boot time, e.g. rootfs=ext2
+/* this can be set at boot time, e.g. rootfstype=ext2
* if set to invalid value or if read_super() fails on the specified
* filesystem type then mount_root() will go through all registered filesystems.
*/
-static char rootfs[128] __initdata = "ext2";
+static char rootfstype[32] __initdata = "";
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
@@ -90,11 +90,11 @@
int n = strlen(line) + 1;
if (n > 1 && n < 128)
- strncpy(rootfs, line, n);
+ strncpy(rootfstype, line, n);
return 1;
}
-__setup("rootfs=", rootfs_setup);
+__setup("rootfstype=", rootfs_setup);
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
@@ -1479,7 +1479,7 @@
void __init mount_root(void)
{
- struct file_system_type * fs_type;
+ struct file_system_type * fs_type = NULL;
struct super_block * sb;
struct vfsmount *vfsmnt;
struct block_device *bdev = NULL;
@@ -1597,11 +1597,15 @@
goto mount_it;
}
- fs_type = get_fs_type(rootfs);
- if (fs_type) {
- sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
- if (sb)
- goto mount_it;
+ if (*rootfstype) {
+ fs_type = get_fs_type(rootfstype);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* do NOT try all filesystems - user explicitly wanted this one */
+ goto fail;
}
read_lock(_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
@@ -1617,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(_systems_lock);
+fail:
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
[Tigran Aivazian]
> no, because it would cause a "spurious" call to get_fs_type("") which
> we don't want to happen (by default i.e. -- if user _really_ wants it
> that is ok). The default of "ext2" is fine.
I still disagree -- super.c is no place to dictate the default root
filesystem. And I agree with Andries that 'rootfs=' is confusing.
Peter
--- 2.4.0test13pre3+rootfs/fs/super.c~ Mon Dec 18 09:06:47 2000
+++ 2.4.0test13pre3+rootfs/fs/super.c Mon Dec 18 09:09:48 2000
@@ -18,7 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
- * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
+ * Added rootfstype boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -59,11 +59,11 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
-/* this can be set at boot time, e.g. rootfs=ext2
+/* this can be set at boot time, e.g. rootfstype=ext2
* if set to invalid value or if read_super() fails on the specified
* filesystem type then mount_root() will go through all registered filesystems.
*/
-static char rootfs[128] __initdata = "ext2";
+static char rootfstype[32] __initdata = "";
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
@@ -90,11 +90,11 @@
int n = strlen(line) + 1;
if (n > 1 && n < 128)
- strncpy(rootfs, line, n);
+ strncpy(rootfstype, line, n);
return 1;
}
-__setup("rootfs=", rootfs_setup);
+__setup("rootfstype=", rootfs_setup);
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
@@ -1479,7 +1479,7 @@
void __init mount_root(void)
{
- struct file_system_type * fs_type;
+ struct file_system_type * fs_type = NULL;
struct super_block * sb;
struct vfsmount *vfsmnt;
struct block_device *bdev = NULL;
@@ -1597,7 +1597,8 @@
goto mount_it;
}
- fs_type = get_fs_type(rootfs);
+ if (*rootfstype)
+ fs_type = get_fs_type(rootfstype);
if (fs_type) {
sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
if (sb)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.0-test13-pre3: Makefile problem in drivers/video
Peter, Alan, thanks, this solved the problem - 2.4.0-test13pre3 is up 'n running ;) BTW: Is it possible to shut off these "apic error on CPU0" messages." Now I know that my board is not well designed, so what should these messages help me? They blow up my /var/log/messages only... kind regards Norbert On Monday 18 December 2000 08:35, Peter Samuelson wrote: > [Norbert Breun] > > > The problem is, there should be a directory "media" under > > /lib/modules/2.4.0-test12.old/kernel/drivers/ and this is missing in > > test13pre2 and test13pre3. The modules are not built. > > Does this help? I think it's right. > > Peter > > diff -urk.orig 2.4.0test13pre3/drivers/media/Makefile > --- 2.4.0test13pre3/drivers/media/Makefile.orig Sat Dec 16 06:18:16 2000 > +++ 2.4.0test13pre3/drivers/media/MakefileMon Dec 18 01:32:34 2000 > @@ -10,6 +10,7 @@ > # > > subdir-y := video radio > +subdir-m := video radio > > O_TARGET := media.o > obj-y:= $(join $(subdir-y),$(subdir-y:%=/%.o)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
Hi Linus,
On Sun, 17 Dec 2000, Linus Torvalds wrote:
> The shmfs cleanup should be unnoticeable except to users who use SAP
> with huge shared memory segments, where Christoph Rohlands work not
> only makes the code much more readable, it should also make it
> dependable..
:-)
The appended patch fixes the following:
1) We cannot unlock the page in shmem_writepage on ooswap since
page_launder will do this later.
2) We should set the inode number of SYSV segments to the (user) shmid
and not the internal id.
Greetings
Christoph
diff -uNr 4-13-3/mm/shmem.c c/mm/shmem.c
--- 4-13-3/mm/shmem.c Mon Dec 18 15:08:32 2000
+++ c/mm/shmem.cMon Dec 18 15:13:10 2000
@@ -210,37 +210,39 @@
{
int error;
struct shmem_inode_info *info;
- swp_entry_t *entry;
+ swp_entry_t *entry, swap;
info = &((struct inode *)page->mapping->host)->u.shmem_i;
if (info->locked)
return 1;
- spin_lock(>lock);
- entry = shmem_swp_entry (info, page->index);
- if (!entry) /* this had been allocted on page allocation */
- BUG();
- error = -EAGAIN;
- if (entry->val)
- goto out;
-
/*
* 1 means "cannot write out".
* We can't drop dirty pages
* just because we ran out of
* swap.
*/
- error = 1;
- *entry = __get_swap_page(2);
- if (!entry->val)
+ swap = __get_swap_page(2);
+ if (!swap.val)
+ return 1;
+
+ spin_lock(>lock);
+ entry = shmem_swp_entry (info, page->index);
+ if (!entry) /* this had been allocted on page allocation */
+ BUG();
+ error = -EAGAIN;
+ if (entry->val) {
+__swap_free(swap, 2);
goto out;
+}
+*entry = swap;
error = 0;
/* Remove the from the page cache */
lru_cache_del(page);
remove_inode_page(page);
/* Add it to the swap cache */
- add_to_swap_cache(page,*entry);
+ add_to_swap_cache(page, swap);
page_cache_release(page);
SetPageDirty(page);
info->swapped++;
diff -uNr 4-13-3/ipc/shm.c c/ipc/shm.c
--- 4-13-3/ipc/shm.cMon Dec 18 15:08:32 2000
+++ c/ipc/shm.c Mon Dec 18 15:13:58 2000
@@ -220,7 +220,7 @@
shp->shm_segsz = size;
shp->id = shm_buildid(id,shp->shm_perm.seq);
shp->shm_file = file;
- file->f_dentry->d_inode->i_ino = id;
+ file->f_dentry->d_inode->i_ino = shp->id;
file->f_op = _file_operations;
shm_tot += numpages;
shm_unlock (id);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
In article <[EMAIL PROTECTED]> you write: > [J Sloan] > > The module now compiles and gets installed - > > Unfortunately, attempting to load it does not go well: > > > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range >... > Those symbols are rather generic and rather important. Sounds like a > generic module problem. Do other modules load? Does your kernel use > MODVERSIONS? (This module apparently doesn't.) Are you using a recent > version of modutils? The most important question: Did you run "make dep" after doing the patch? Olaf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
From: Tigran Aivazian <[EMAIL PROTECTED]>
+rootfs=[KNL] Use filesystem type specified (e.g. rootfs=ext2) for
root.
(i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
It gives some property of the root filesystem, but which?
+static char rootfs[128] __initdata = "ext2";
(ii) It is a bad idea to arbitrarily select "ext2".
Moreover, we want to recognize the case where a boot option was given,
see below.
+fs_type = get_fs_type(rootfs);
+if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+if (sb)
+goto mount_it;
+}
(iii) I probably give the rootfstype explicitly because bad things
(like disk corruption) happen when the kernel misrecognizes some
filesystem, and perhaps starts updating access times or so.
Thus, if the boot option rootfstype is given, I prefer a boot failure
over a kernel attempt to try all filesystems it knows about, just like
mount(8) only will start guessing when no explicit type was given.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000, Peter Samuelson wrote:
>
> [Tigran Aivazian]
> > +/* this can be set at boot time, e.g. rootfs=ext2
> > + * if set to invalid value or if read_super() fails on the specified
> > + * filesystem type then mount_root() will go through all registered filesystems.
> > + */
> > +static char rootfs[128] __initdata = "ext2";
>
> Better that we not hard-code anything here. If we want ext2 to be
> tried first, we should link it first, which we already do.
>
no, because it would cause a "spurious" call to get_fs_type("") which we
don't want to happen (by default i.e. -- if user _really_ wants it
that is ok). The default of "ext2" is fine.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
Hi,
What is this change about?
diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c
linux/arch/i386/kernel/smpboot.c
--- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
+++ linux/arch/i386/kernel/smpboot.cThu Dec 14 14:54:40 2000
@@ -694,6 +694,11 @@
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip >> 12));
+ /*
+* Give the other CPU some time to accept the IPI.
+*/
+ udelay(300);
+
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
There is the following code is just after it, making the above change
just useless garbage:
timeout = 0;
do {
Dprintk("+");
udelay(100);
send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
} while (send_status && (timeout++ < 1000));
/*
* Give the other CPU some time to accept the IPI.
*/
udelay(200);
If we need 600usecs of delay for certain systems, then why not just make
it like below?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
patch-2.0.4-test13-pre3-startup_ipi-0
diff -up --recursive --new-file
linux-2.4.0-test13-pre3.macro/arch/i386/kernel/smpboot.c
linux-2.4.0-test13-pre3/arch/i386/kernel/smpboot.c
--- linux-2.4.0-test13-pre3.macro/arch/i386/kernel/smpboot.c Mon Dec 18 12:14:10
2000
+++ linux-2.4.0-test13-pre3/arch/i386/kernel/smpboot.c Mon Dec 18 12:15:49 2000
@@ -694,11 +694,6 @@ static void __init do_boot_cpu (int apic
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip >> 12));
- /*
-* Give the other CPU some time to accept the IPI.
-*/
- udelay(300);
-
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
@@ -712,7 +707,7 @@ static void __init do_boot_cpu (int apic
/*
* Give the other CPU some time to accept the IPI.
*/
- udelay(200);
+ udelay(500);
/*
* Due to the Pentium erratum 3AP.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
[Tigran Aivazian] > +/* this can be set at boot time, e.g. rootfs=ext2 > + * if set to invalid value or if read_super() fails on the specified > + * filesystem type then mount_root() will go through all registered filesystems. > + */ > +static char rootfs[128] __initdata = "ext2"; Better that we not hard-code anything here. If we want ext2 to be tried first, we should link it first, which we already do. Peter [hand-edited patch, may not be right!] --- linux/fs/super.cTue Dec 12 09:25:22 2000 +++ rootfs/fs/super.c Mon Dec 18 10:03:31 2000 @@ -63,7 +63,7 @@ * if set to invalid value or if read_super() fails on the specified * filesystem type then mount_root() will go through all registered filesystems. */ -static char rootfs[128] __initdata = "ext2"; +static char rootfs[32] __initdata = ""; int nr_super_blocks; int max_super_blocks = NR_SUPER; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
"Tigran Aivazian wrote:" > In November last year I wrote support for a new boot parameter called > "rootfs" implementing functionality similar to UnixWare7, i.e. being > able to specify the filesystem type to try first in mount_root() and if > this fails then go on to the usual loop over all registered filesystems. > > At the time it was of pure academical interest (i.e. generally useful to > everybody) but now I realized that it is actually quite critical, i.e. > there exist filesystems (e.g. ext2) which are not able to detect their > structural integrity beyond simple damage to the superblock. So, as a It is more critical now if one wants to use eg. UMSDOS filesystem as root fs. As the msdos filesystem is linked first system always tries to use it first when there is a FAT filesystem on the root device. One way of solving the problem is the "rootfs" parameter. Changing link sequence to be non-alphabetic is another choice... However, it is a separate issue that UMSDOS-root is broken in 2.4 at the moment. But I hope it is not a permanent state. > diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt >rootfs/Documentation/kernel-parameters.txt > --- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000 > +++ rootfs/Documentation/kernel-parameters.txtMon Dec 18 09:04:06 2000 > @@ -473,7 +473,10 @@ > > ro [KNL] Mount root device read-only on boot. > > - root= [KNL] root filesystem. > + root= [KNL] Mount root filesystem on specified (as hex or >"/dev/XXX") device. > + > + rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for >root. > + > > rw [KNL] Mount root device read-write on boot. > Regards Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. & Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test13-pre3: Makefile problem in drivers/video
> you may be right there is no module "video.o". The problem is, there should > be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/ > and this is missing in test13pre2 and test13pre3. The modules are not built. Its a small makefile error again. The directories are not listed as containing modules. Fix that and they are happy. --- drivers/media/Makefile~ Sun Dec 17 21:28:20 2000 +++ drivers/media/Makefile Mon Dec 18 10:59:25 2000 @@ -10,6 +10,7 @@ # subdir-y := video radio +mod-subdirs := video radio O_TARGET := media.o obj-y:= $(join $(subdir-y),$(subdir-y:%=/%.o)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test13-pre3] rootfs boot param. support
Hi Linus,
In November last year I wrote support for a new boot parameter called
"rootfs" implementing functionality similar to UnixWare7, i.e. being
able to specify the filesystem type to try first in mount_root() and if
this fails then go on to the usual loop over all registered filesystems.
At the time it was of pure academical interest (i.e. generally useful to
everybody) but now I realized that it is actually quite critical, i.e.
there exist filesystems (e.g. ext2) which are not able to detect their
structural integrity beyond simple damage to the superblock. So, as a
result, I have kernel panics because it successfully mounts the garbage as
a valid ext2 filesystem simply because the real filesystem on the block
device happens to use the location of the block containing superblock
different than ext2.
Therefore, please consider this tiny patch, tested against
2.4.0-test13-pre3.
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 10:03:31 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch <[EMAIL PROTECTED]>, 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will go through all registered filesystems.
+ */
+static char rootfs[128] __initdata = "ext2";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n > 1 && n < 128)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,12 @@
goto mount_it;
}
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
read_lock(_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type->next) {
if (!(fs_type->fs_flags & FS_REQUIRES_DEV))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test13-pre3: unresolved symbols in dsbr100.o, ibmcam.o and ov511.o
depmod -ae -F System.map 2.4.0-test13-pre3 depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/dsbr100.o depmod: video_register_device depmod: video_unregister_device depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/ibmcam.o depmod: video_register_device depmod: video_unregister_device depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/ov511.o depmod: video_proc_entry depmod: video_register_device depmod: video_unregister_device - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
[J Sloan] > The module now compiles and gets installed - > Unfortunately, attempting to load it does not go well: > > kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range > kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up > kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add > kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user > kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule > kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc > kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo Those symbols are rather generic and rather important. Sounds like a generic module problem. Do other modules load? Does your kernel use MODVERSIONS? (This module apparently doesn't.) Are you using a recent version of modutils? Puzzled. Maybe Keith Owens knows something. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
Niels Kristian Bech Jensen wrote: > Does this patch fix your problem? > > --- test13-pre3/drivers/char/Makefile Mon Dec 18 01:21:31 2000 > +++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000 > @@ -16,6 +16,8 @@ > > O_TARGET := char.o > > +mod-subdirs := drm > + > obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o > Some progress anyway; The module now compiles and gets installed - Unfortunately, attempting to load it does not go well: /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol create_proc_entry /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol inter_module_put /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __get_free_pages /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol boot_cpu_data /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol inter_module_get /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol remove_wait_queue /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol high_memory /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol iounmap /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol free_pages /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __ioremap /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol del_timer /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol interruptible_sleep_on /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __pollwait /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol kfree /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol remove_proc_entry /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol pci_find_slot/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol kill_fasync /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol fasync_helper /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol add_wait_queue /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol do_mmap_pgoff /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol mem_map /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol sprintf /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol jiffies /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol printk /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol add_timer /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_to_user /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: insmod /lib/modul es/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o failed /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: insmod tdfx failed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
Niels Kristian Bech Jensen wrote: Does this patch fix your problem? --- test13-pre3/drivers/char/Makefile Mon Dec 18 01:21:31 2000 +++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000 @@ -16,6 +16,8 @@ O_TARGET := char.o +mod-subdirs := drm + obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o Some progress anyway; The module now compiles and gets installed - Unfortunately, attempting to load it does not go well: /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol create_proc_entry /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol inter_module_put /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __get_free_pages /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol boot_cpu_data /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol inter_module_get /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol remove_wait_queue /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol high_memory /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol iounmap /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol free_pages /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __ioremap /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol del_timer /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol interruptible_sleep_on /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __pollwait /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol kfree /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol remove_proc_entry /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol pci_find_slot/lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol kill_fasync /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol fasync_helper /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol add_wait_queue /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol do_mmap_pgoff /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol mem_map /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol sprintf /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol jiffies /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol printk /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol add_timer /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_to_user /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: insmod /lib/modul es/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o failed /lib/modules/2.4.0-test13-pre3/kernel/drivers/char/drm/tdfx.o: insmod tdfx failed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
[J Sloan] The module now compiles and gets installed - Unfortunately, attempting to load it does not go well: kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo Those symbols are rather generic and rather important. Sounds like a generic module problem. Do other modules load? Does your kernel use MODVERSIONS? (This module apparently doesn't.) Are you using a recent version of modutils? Puzzled. Maybe Keith Owens knows something. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test13-pre3: unresolved symbols in dsbr100.o, ibmcam.o and ov511.o
depmod -ae -F System.map 2.4.0-test13-pre3 depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/dsbr100.o depmod: video_register_device depmod: video_unregister_device depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/ibmcam.o depmod: video_register_device depmod: video_unregister_device depmod: *** Unresolved symbols in /lib/modules/2.4.0-test13-pre3/kernel/drivers/usb/ov511.o depmod: video_proc_entry depmod: video_register_device depmod: video_unregister_device - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test13-pre3] rootfs boot param. support
Hi Linus,
In November last year I wrote support for a new boot parameter called
"rootfs" implementing functionality similar to UnixWare7, i.e. being
able to specify the filesystem type to try first in mount_root() and if
this fails then go on to the usual loop over all registered filesystems.
At the time it was of pure academical interest (i.e. generally useful to
everybody) but now I realized that it is actually quite critical, i.e.
there exist filesystems (e.g. ext2) which are not able to detect their
structural integrity beyond simple damage to the superblock. So, as a
result, I have kernel panics because it successfully mounts the garbage as
a valid ext2 filesystem simply because the real filesystem on the block
device happens to use the location of the block containing superblock
different than ext2.
Therefore, please consider this tiny patch, tested against
2.4.0-test13-pre3.
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 10:03:31 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include linux/config.h
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will go through all registered filesystems.
+ */
+static char rootfs[128] __initdata = "ext2";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n 1 n 128)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,12 @@
goto mount_it;
}
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
read_lock(file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type-next) {
if (!(fs_type-fs_flags FS_REQUIRES_DEV))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test13-pre3: Makefile problem in drivers/video
you may be right there is no module "video.o". The problem is, there should be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/ and this is missing in test13pre2 and test13pre3. The modules are not built. Its a small makefile error again. The directories are not listed as containing modules. Fix that and they are happy. --- drivers/media/Makefile~ Sun Dec 17 21:28:20 2000 +++ drivers/media/Makefile Mon Dec 18 10:59:25 2000 @@ -10,6 +10,7 @@ # subdir-y := video radio +mod-subdirs := video radio O_TARGET := media.o obj-y:= $(join $(subdir-y),$(subdir-y:%=/%.o)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
"Tigran Aivazian wrote:" In November last year I wrote support for a new boot parameter called "rootfs" implementing functionality similar to UnixWare7, i.e. being able to specify the filesystem type to try first in mount_root() and if this fails then go on to the usual loop over all registered filesystems. At the time it was of pure academical interest (i.e. generally useful to everybody) but now I realized that it is actually quite critical, i.e. there exist filesystems (e.g. ext2) which are not able to detect their structural integrity beyond simple damage to the superblock. So, as a It is more critical now if one wants to use eg. UMSDOS filesystem as root fs. As the msdos filesystem is linked first system always tries to use it first when there is a FAT filesystem on the root device. One way of solving the problem is the "rootfs" parameter. Changing link sequence to be non-alphabetic is another choice... However, it is a separate issue that UMSDOS-root is broken in 2.4 at the moment. But I hope it is not a permanent state. diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt rootfs/Documentation/kernel-parameters.txt --- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000 +++ rootfs/Documentation/kernel-parameters.txtMon Dec 18 09:04:06 2000 @@ -473,7 +473,10 @@ ro [KNL] Mount root device read-only on boot. - root= [KNL] root filesystem. + root= [KNL] Mount root filesystem on specified (as hex or "/dev/XXX") device. + + rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for root. + rw [KNL] Mount root device read-write on boot. Regards Andrzej -- === Andrzej M. Krzysztofowicz [EMAIL PROTECTED] phone (48)(58) 347 14 61 Faculty of Applied Phys. Math., Technical University of Gdansk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
[Tigran Aivazian] +/* this can be set at boot time, e.g. rootfs=ext2 + * if set to invalid value or if read_super() fails on the specified + * filesystem type then mount_root() will go through all registered filesystems. + */ +static char rootfs[128] __initdata = "ext2"; Better that we not hard-code anything here. If we want ext2 to be tried first, we should link it first, which we already do. Peter [hand-edited patch, may not be right!] --- linux/fs/super.cTue Dec 12 09:25:22 2000 +++ rootfs/fs/super.c Mon Dec 18 10:03:31 2000 @@ -63,7 +63,7 @@ * if set to invalid value or if read_super() fails on the specified * filesystem type then mount_root() will go through all registered filesystems. */ -static char rootfs[128] __initdata = "ext2"; +static char rootfs[32] __initdata = ""; int nr_super_blocks; int max_super_blocks = NR_SUPER; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
Hi,
What is this change about?
diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c
linux/arch/i386/kernel/smpboot.c
--- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
+++ linux/arch/i386/kernel/smpboot.cThu Dec 14 14:54:40 2000
@@ -694,6 +694,11 @@
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip 12));
+ /*
+* Give the other CPU some time to accept the IPI.
+*/
+ udelay(300);
+
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
There is the following code is just after it, making the above change
just useless garbage:
timeout = 0;
do {
Dprintk("+");
udelay(100);
send_status = apic_read(APIC_ICR) APIC_ICR_BUSY;
} while (send_status (timeout++ 1000));
/*
* Give the other CPU some time to accept the IPI.
*/
udelay(200);
If we need 600usecs of delay for certain systems, then why not just make
it like below?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--+
+e-mail: [EMAIL PROTECTED], PGP key available+
patch-2.0.4-test13-pre3-startup_ipi-0
diff -up --recursive --new-file
linux-2.4.0-test13-pre3.macro/arch/i386/kernel/smpboot.c
linux-2.4.0-test13-pre3/arch/i386/kernel/smpboot.c
--- linux-2.4.0-test13-pre3.macro/arch/i386/kernel/smpboot.cMon Dec 18 12:14:10
2000
+++ linux-2.4.0-test13-pre3/arch/i386/kernel/smpboot.c Mon Dec 18 12:15:49 2000
@@ -694,11 +694,6 @@ static void __init do_boot_cpu (int apic
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip 12));
- /*
-* Give the other CPU some time to accept the IPI.
-*/
- udelay(300);
-
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
@@ -712,7 +707,7 @@ static void __init do_boot_cpu (int apic
/*
* Give the other CPU some time to accept the IPI.
*/
- udelay(200);
+ udelay(500);
/*
* Due to the Pentium erratum 3AP.
*/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000, Peter Samuelson wrote:
[Tigran Aivazian]
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will go through all registered filesystems.
+ */
+static char rootfs[128] __initdata = "ext2";
Better that we not hard-code anything here. If we want ext2 to be
tried first, we should link it first, which we already do.
no, because it would cause a "spurious" call to get_fs_type("") which we
don't want to happen (by default i.e. -- if user _really_ wants it
that is ok). The default of "ext2" is fine.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
From: Tigran Aivazian [EMAIL PROTECTED]
+rootfs=[KNL] Use filesystem type specified (e.g. rootfs=ext2) for
root.
(i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
It gives some property of the root filesystem, but which?
+static char rootfs[128] __initdata = "ext2";
(ii) It is a bad idea to arbitrarily select "ext2".
Moreover, we want to recognize the case where a boot option was given,
see below.
+fs_type = get_fs_type(rootfs);
+if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+if (sb)
+goto mount_it;
+}
(iii) I probably give the rootfstype explicitly because bad things
(like disk corruption) happen when the kernel misrecognizes some
filesystem, and perhaps starts updating access times or so.
Thus, if the boot option rootfstype is given, I prefer a boot failure
over a kernel attempt to try all filesystems it knows about, just like
mount(8) only will start guessing when no explicit type was given.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
In article [EMAIL PROTECTED] you write: [J Sloan] The module now compiles and gets installed - Unfortunately, attempting to load it does not go well: kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range ... Those symbols are rather generic and rather important. Sounds like a generic module problem. Do other modules load? Does your kernel use MODVERSIONS? (This module apparently doesn't.) Are you using a recent version of modutils? The most important question: Did you run "make dep" after doing the patch? Olaf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
Hi Linus,
On Sun, 17 Dec 2000, Linus Torvalds wrote:
The shmfs cleanup should be unnoticeable except to users who use SAP
with huge shared memory segments, where Christoph Rohlands work not
only makes the code much more readable, it should also make it
dependable..
:-)
The appended patch fixes the following:
1) We cannot unlock the page in shmem_writepage on ooswap since
page_launder will do this later.
2) We should set the inode number of SYSV segments to the (user) shmid
and not the internal id.
Greetings
Christoph
diff -uNr 4-13-3/mm/shmem.c c/mm/shmem.c
--- 4-13-3/mm/shmem.c Mon Dec 18 15:08:32 2000
+++ c/mm/shmem.cMon Dec 18 15:13:10 2000
@@ -210,37 +210,39 @@
{
int error;
struct shmem_inode_info *info;
- swp_entry_t *entry;
+ swp_entry_t *entry, swap;
info = ((struct inode *)page-mapping-host)-u.shmem_i;
if (info-locked)
return 1;
- spin_lock(info-lock);
- entry = shmem_swp_entry (info, page-index);
- if (!entry) /* this had been allocted on page allocation */
- BUG();
- error = -EAGAIN;
- if (entry-val)
- goto out;
-
/*
* 1 means "cannot write out".
* We can't drop dirty pages
* just because we ran out of
* swap.
*/
- error = 1;
- *entry = __get_swap_page(2);
- if (!entry-val)
+ swap = __get_swap_page(2);
+ if (!swap.val)
+ return 1;
+
+ spin_lock(info-lock);
+ entry = shmem_swp_entry (info, page-index);
+ if (!entry) /* this had been allocted on page allocation */
+ BUG();
+ error = -EAGAIN;
+ if (entry-val) {
+__swap_free(swap, 2);
goto out;
+}
+*entry = swap;
error = 0;
/* Remove the from the page cache */
lru_cache_del(page);
remove_inode_page(page);
/* Add it to the swap cache */
- add_to_swap_cache(page,*entry);
+ add_to_swap_cache(page, swap);
page_cache_release(page);
SetPageDirty(page);
info-swapped++;
diff -uNr 4-13-3/ipc/shm.c c/ipc/shm.c
--- 4-13-3/ipc/shm.cMon Dec 18 15:08:32 2000
+++ c/ipc/shm.c Mon Dec 18 15:13:58 2000
@@ -220,7 +220,7 @@
shp-shm_segsz = size;
shp-id = shm_buildid(id,shp-shm_perm.seq);
shp-shm_file = file;
- file-f_dentry-d_inode-i_ino = id;
+ file-f_dentry-d_inode-i_ino = shp-id;
file-f_op = shm_file_operations;
shm_tot += numpages;
shm_unlock (id);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.0-test13-pre3: Makefile problem in drivers/video
Peter, Alan, thanks, this solved the problem - 2.4.0-test13pre3 is up 'n running ;) BTW: Is it possible to shut off these "apic error on CPU0" messages." Now I know that my board is not well designed, so what should these messages help me? They blow up my /var/log/messages only... kind regards Norbert On Monday 18 December 2000 08:35, Peter Samuelson wrote: [Norbert Breun] The problem is, there should be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/ and this is missing in test13pre2 and test13pre3. The modules are not built. Does this help? I think it's right. Peter diff -urk.orig 2.4.0test13pre3/drivers/media/Makefile --- 2.4.0test13pre3/drivers/media/Makefile.orig Sat Dec 16 06:18:16 2000 +++ 2.4.0test13pre3/drivers/media/MakefileMon Dec 18 01:32:34 2000 @@ -10,6 +10,7 @@ # subdir-y := video radio +subdir-m := video radio O_TARGET := media.o obj-y:= $(join $(subdir-y),$(subdir-y:%=/%.o)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
[Tigran Aivazian]
no, because it would cause a "spurious" call to get_fs_type("") which
we don't want to happen (by default i.e. -- if user _really_ wants it
that is ok). The default of "ext2" is fine.
I still disagree -- super.c is no place to dictate the default root
filesystem. And I agree with Andries that 'rootfs=' is confusing.
Peter
--- 2.4.0test13pre3+rootfs/fs/super.c~ Mon Dec 18 09:06:47 2000
+++ 2.4.0test13pre3+rootfs/fs/super.c Mon Dec 18 09:09:48 2000
@@ -18,7 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
- * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
+ * Added rootfstype boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include linux/config.h
@@ -59,11 +59,11 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
-/* this can be set at boot time, e.g. rootfs=ext2
+/* this can be set at boot time, e.g. rootfstype=ext2
* if set to invalid value or if read_super() fails on the specified
* filesystem type then mount_root() will go through all registered filesystems.
*/
-static char rootfs[128] __initdata = "ext2";
+static char rootfstype[32] __initdata = "";
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
@@ -90,11 +90,11 @@
int n = strlen(line) + 1;
if (n 1 n 128)
- strncpy(rootfs, line, n);
+ strncpy(rootfstype, line, n);
return 1;
}
-__setup("rootfs=", rootfs_setup);
+__setup("rootfstype=", rootfs_setup);
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
@@ -1479,7 +1479,7 @@
void __init mount_root(void)
{
- struct file_system_type * fs_type;
+ struct file_system_type * fs_type = NULL;
struct super_block * sb;
struct vfsmount *vfsmnt;
struct block_device *bdev = NULL;
@@ -1597,7 +1597,8 @@
goto mount_it;
}
- fs_type = get_fs_type(rootfs);
+ if (*rootfstype)
+ fs_type = get_fs_type(rootfstype);
if (fs_type) {
sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
if (sb)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000, Peter Samuelson wrote:
[Tigran Aivazian]
no, because it would cause a "spurious" call to get_fs_type("") which
we don't want to happen (by default i.e. -- if user _really_ wants it
that is ok). The default of "ext2" is fine.
I still disagree -- super.c is no place to dictate the default root
filesystem. And I agree with Andries that 'rootfs=' is confusing.
I have already covered both of these issues in the email I sent ages
ago... Here it is below (instead of re-sending) (the original got lost
because of the mail-abuse vs btconnect's randomness)
From [EMAIL PROTECTED] Mon Dec 18 15:20:08 2000
Date: Mon, 18 Dec 2000 14:44:32 + (GMT)
From: Tigran Aivazian [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000 [EMAIL PROTECTED] wrote:
(i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
It gives some property of the root filesystem, but which?
No, it is not ambiguous. Because, look at this sequence:
"ffs", "ufs", "bfs", "reiserfs", "vxfs", "sockfs", "pipefs", "nfs", ...
they are familiar to everyone and everyone immediately recognizes the
attribute they describe by the ending "fs". So, the attribute is
immediately obvious and should be recognized by programmer without need to
explicitly comment about it (it just is like it is _obvious_ that static
int x; is initialized to 0 and there is no need to start asking oneself
"what is this attribute of x that is being set to 0 here... ah.. it's the
_value_ thereof!" )
+static char rootfs[128] __initdata = "ext2";
(ii) It is a bad idea to arbitrarily select "ext2".
No, how could you say it is a bad idea without saying also _what_ is a
good idea? If there is no replacement for a bad idea then it is, by
definition, a good (or best) idea. So, having not found a better initial
value for rootfs[] I set it to "ext2". Setting it to "" is no good as I
explained to Peter. Setting it to NULL is also no good because needs an
extra line of code in mount_root() to check for it. So, what then? I say
"ext2" as it is the most popular Linux filesystem at the moment.
(iii) I probably give the rootfstype explicitly because bad things
(like disk corruption) happen when the kernel misrecognizes some
filesystem, and perhaps starts updating access times or so.
Thus, if the boot option rootfstype is given, I prefer a boot failure
over a kernel attempt to try all filesystems it knows about, just like
mount(8) only will start guessing when no explicit type was given.
that gives it a different semantics, i.e. you are changing the rules. I am
not sure which rules are better but there are advantages to it being as
is, e.g. one could hardcode "rootfs=vxfs" in their lilo.conf and rely on
fallback to ext2 for some of the partitions but not others.
This one is a matter of taste and if Linus says your way is better I will
redo the patch immediately. Both ways are fine with me.
Regards,
Tigran
From [EMAIL PROTECTED] Mon Dec 18 15:20:13 2000
Date: Mon, 18 Dec 2000 14:54:40 + (GMT)
From: Tigran Aivazian [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
On Mon, 18 Dec 2000, Tigran Aivazian wrote:
Setting it to NULL is also no good because needs an
extra line of code in mount_root() to check for it.
before N people misunderstand the above -- I meant having just a
pointer and doing kmalloc/kfree manually.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
[Andries Brouwer]
(i) I prefer "rootfstype". Indeed, "rootfs" is ambiguous.
It gives some property of the root filesystem, but which?
(ii) It is a bad idea to arbitrarily select "ext2".
(iii) [...] Thus, if the boot option rootfstype is given, I prefer a
boot failure over a kernel attempt to try all filesystems it knows
Agreed on all counts.
Peter
--- test13pre3+rootfs/fs/super.c~ Mon Dec 18 09:06:47 2000
+++ test13pre3+rootfs/fs/super.cMon Dec 18 09:18:02 2000
@@ -18,7 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
- * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
+ * Added rootfstype boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include linux/config.h
@@ -59,11 +59,11 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
-/* this can be set at boot time, e.g. rootfs=ext2
+/* this can be set at boot time, e.g. rootfstype=ext2
* if set to invalid value or if read_super() fails on the specified
* filesystem type then mount_root() will go through all registered filesystems.
*/
-static char rootfs[128] __initdata = "ext2";
+static char rootfstype[32] __initdata = "";
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
@@ -90,11 +90,11 @@
int n = strlen(line) + 1;
if (n 1 n 128)
- strncpy(rootfs, line, n);
+ strncpy(rootfstype, line, n);
return 1;
}
-__setup("rootfs=", rootfs_setup);
+__setup("rootfstype=", rootfs_setup);
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
@@ -1479,7 +1479,7 @@
void __init mount_root(void)
{
- struct file_system_type * fs_type;
+ struct file_system_type * fs_type = NULL;
struct super_block * sb;
struct vfsmount *vfsmnt;
struct block_device *bdev = NULL;
@@ -1597,11 +1597,15 @@
goto mount_it;
}
- fs_type = get_fs_type(rootfs);
- if (fs_type) {
- sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
- if (sb)
- goto mount_it;
+ if (*rootfstype) {
+ fs_type = get_fs_type(rootfstype);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* do NOT try all filesystems - user explicitly wanted this one */
+ goto fail;
}
read_lock(file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type-next) {
@@ -1617,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(file_systems_lock);
+fail:
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs boot param. support
Ok, the version below doesn't look too bad, except a couple things, see
below:
On Mon, 18 Dec 2000, Peter Samuelson wrote:
-__setup("rootfs=", rootfs_setup);
+__setup("rootfstype=", rootfs_setup);
this is wrong. If the parameter is "rootfstype" then the function is
rootfstype_setup(). Too long. No, "rootfs" was a good idea to beging with
(ask any kernel hacker who wrote UW7 BCP support -- they knew what they
were calling their variables :)
{
- struct file_system_type * fs_type;
+ struct file_system_type * fs_type = NULL;
this is not needed. Why did you put it there?
+ if (*rootfstype) {
+ fs_type = get_fs_type(rootfstype);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* do NOT try all filesystems - user explicitly wanted this one */
+ goto fail;
...
+fail:
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
we should also print out the filesystem type, so instead of having a fail
label I would put the panic() inside the code above.
I will redo the patch with your and Andries' comments in place and re-send
to Linus. Namely, the useful things, imho, from your suggestions are:
a) the space allocated for it should be 32 bytes and not 128
b) we should check if user passed any value and only then activate the
code
c) default value "" is ok (ok, fine, the extra line of code to check for
it is not too bad).
d) but the variable should still be called "rootfs" and not
"rootfstype". rootfstype is too long, too confusing and not
obvious. Whilst "rootfs" immediately tells you "it's the name of the
filesystem in the namespace defined by file_system_type-name"
Oh, btw you changed one place from 128 to 32 but forgot another -- never
mind :)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch-2.4.0-test13-pre3] rootfs (2nd attempt)
Hi Linus,
Thanks to suggestions from Andries and Peter I enhanced the rootfs patch
to do the same it did before + panic when rootfs= is given but failed to
match the userspace mount(8) behaviour. Also other cleanups mentioned in
the thread are all incorporated (well, at least the sensible ones). Now,
everyone is (hopefully) happy.
Tested under 2.4.0-test13-pre3.
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 14:49:08 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include linux/config.h
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will go through all registered filesystems.
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n 1 n 32)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type-next) {
if (!(fs_type-fs_flags FS_REQUIRES_DEV))
@@ -1593,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(file_systems_lock);
+fail:
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Oops Re: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
just a typo in the comment, sorry. Corrected version below.
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 15:03:44 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include linux/config.h
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n 1 n 32)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type-next) {
if (!(fs_type-fs_flags FS_REQUIRES_DEV))
@@ -1593,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(file_systems_lock);
+fail:
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
On 18 Dec 00 at 13:58, Maciej W. Rozycki wrote:
What is this change about?
diff -u --recursive --new-file v2.4.0-test12/linux/arch/i386/kernel/smpboot.c
linux/arch/i386/kernel/smpboot.c
--- v2.4.0-test12/linux/arch/i386/kernel/smpboot.c Mon Dec 11 17:59:43 2000
+++ linux/arch/i386/kernel/smpboot.cThu Dec 14 14:54:40 2000
@@ -694,6 +694,11 @@
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip 12));
+ /*
+* Give the other CPU some time to accept the IPI.
+*/
+ udelay(300);
+
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
There is the following code is just after it, making the above change
just useless garbage:
No. Without udelay() before first printk() it just does not boot on my
motherboard. There were two choices: either remove all printk() from
these loops (define Dprintk to null), or add udelay(x), where x = 200,
before first printk. I sent patch twice to linux-kernel, and to
[EMAIL PROTECTED], and nobody said anything against it.
timeout = 0;
do {
Dprintk("+");
udelay(100);
send_status = apic_read(APIC_ICR) APIC_ICR_BUSY;
} while (send_status (timeout++ 1000));
/*
* Give the other CPU some time to accept the IPI.
*/
udelay(200);
If we need 600usecs of delay for certain systems, then why not just make
it like below?
No. If there is no udelay() before first printk(), on my GA-6VXD7 board
(SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting
for send to finish...'. So maybe we do not need udelay(200) below loop,
but for sure we need udelay() before first printk(). (my board works
without ANY udelay() in smpboot.c, except one I added... This one is
required.) If somebody lives in Prague, and wants to come with logical
analyzer (or if I should come with motherboard), I'm willing to continue
testing. But current idea is that inb/outb done by cursor positioning
code is incompatible with something else done in secondary CPU startup.
(it boots also without any kernel change with 'console=ttyS0,9600', but
it may be caused by slow serial line)
Without delay() both CPU die, and board does not react to anything except
hard reset anymore (and sometime it does not react even to hard reset; lookup
for my messages during last week).
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
On Mon, 18 Dec 2000, Petr Vandrovec wrote: No. Without udelay() before first printk() it just does not boot on my motherboard. There were two choices: either remove all printk() from these loops (define Dprintk to null), or add udelay(x), where x = 200, before first printk. I sent patch twice to linux-kernel, and to [EMAIL PROTECTED], and nobody said anything against it. I see. But are you sure this is the right fix? You may be covering the real problem with this arbitrary delay. I haven't actually noticed any of your previous mails -- given the load on the list I sometimes miss letters with "uninteresting" subjects. No. If there is no udelay() before first printk(), on my GA-6VXD7 board (SMP VIA 694X) only 'Startup point 1.' is printed, but no 'Waiting for send to finish...'. So maybe we do not need udelay(200) below loop, but for sure we need udelay() before first printk(). (my board works without ANY udelay() in smpboot.c, except one I added... This one is required.) If somebody lives in Prague, and wants to come with logical Other delays are imposed by the MPS (most if not all of them). For example there are systems that assert RESET to a CPU as a result of an INIT IPI. These systems need these delays to allow CPUs to recover. analyzer (or if I should come with motherboard), I'm willing to continue testing. But current idea is that inb/outb done by cursor positioning code is incompatible with something else done in secondary CPU startup. Have you tried putting explicit display adapter (other ISA) I/O accesses after sending the IPI to see if they trigger the problem? IPIs are transmitted over the inter-APIC bus and should be completely invisible to other parts of the system. But the code involved in processing a printk() may interact with the one executed by another CPU right after waking it up. It would be worth to investigate it... (it boots also without any kernel change with 'console=ttyS0,9600', but it may be caused by slow serial line) Or by running different code. Without delay() both CPU die, and board does not react to anything except hard reset anymore (and sometime it does not react even to hard reset; lookup for my messages during last week). Now THAT is weird. It might mean a chipset bug. Still no idea how an inter-APIC message might trigger it -- it completely bypasses MB chipset... Hmm, maybe not... Is your I/O APIC discrete (like Intel's 82093AA) or integrated? It appears there are vendors manufacturing I/O APIC clones and this may imply new problems, sigh... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 18:18, Maciej W. Rozycki wrote: On Mon, 18 Dec 2000, Petr Vandrovec wrote: No. Without udelay() before first printk() it just does not boot on my motherboard. There were two choices: either remove all printk() from these loops (define Dprintk to null), or add udelay(x), where x = 200, before first printk. I sent patch twice to linux-kernel, and to [EMAIL PROTECTED], and nobody said anything against it. I see. But are you sure this is the right fix? You may be covering the real problem with this arbitrary delay. It is possible. But it is hard to track, as it works with serial console, and it is not possible to paint characters to VGA screen, as vgacon uses hardware panning instead of scrolling :-( And if it dies, shift-pageup apparently does not work... And filling whole 32KB with some char does not work, as it changes timing too much... analyzer (or if I should come with motherboard), I'm willing to continue testing. But current idea is that inb/outb done by cursor positioning code is incompatible with something else done in secondary CPU startup. Have you tried putting explicit display adapter (other ISA) I/O accesses after sending the IPI to see if they trigger the problem? IPIs are No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA... Without delay() both CPU die, and board does not react to anything except hard reset anymore (and sometime it does not react even to hard reset; lookup for my messages during last week). Now THAT is weird. It might mean a chipset bug. Still no idea how an inter-APIC message might trigger it -- it completely bypasses MB Yes. I could understand if I had to place bigger udelay() after INIT IPI, as this can cause some specific PIII initialization and Intel says that there should not be any MESI traffic during this init (at least I understand it that way). But after startup IPI it should just start executing code... I tried to put 'wbinvd' here and there, but it did not make any change, only udelay() between startup IPI cmd and first printk() did. chipset... Hmm, maybe not... Is your I/O APIC discrete (like Intel's 82093AA) or integrated? It appears there are vendors manufacturing I/O APIC clones and this may imply new problems, sigh... I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge, and VT82C686 (rev 22) ISA bridge. I tried to request documentation of 694X from VIA, but I did not heard from them. They have probably some secrets hidden in their hardware... Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
Tigran, you write:
Thanks to suggestions from Andries and Peter I enhanced the rootfs patch
to do the same it did before + panic when rootfs= is given but failed to
If I could add one thing here (we have had a 2.2 patch like this for testing
with ext3) - if you specify the rootfstype parameter don't use the "quiet"
option to read_super, so you know why it couldn't mount a specific filesystem
as root, and/or print rootfs type in the panic message.
This is especially useful if you have something in LILO that you forgot about...
Cheers, Andreas
=
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 14:49:08 2000
@@ -1600,7 +1600,7 @@
if (*rootfs) {
fs_type = get_fs_type(rootfs);
if (fs_type) {
- sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,1);
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,0);
if (sb)
goto mount_it;
}
@@ -1622,7 +1622,8 @@
}
read_unlock(file_systems_lock);
fail:
- panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
+ panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
+ kdevname(ROOT_DEV));
mount_it:
printk ("VFS: Mounted root (%s filesystem)%s.\n",
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[final] Re: [patch-2.4.0-test13-pre3] rootfs (2nd attempt)
On Mon, 18 Dec 2000, Andreas Dilger wrote:
If I could add one thing here (we have had a 2.2 patch like this for testing
with ext3) - if you specify the rootfstype parameter don't use the "quiet"
option to read_super, so you know why it couldn't mount a specific filesystem
as root, and/or print rootfs type in the panic message.
Agree completely.
Here is the hopefully final version. Sorry, Linus, I thought the first
version was final :) Looks like I have missed a couple of very useful
things... Thanks to all who commented!
Regards,
Tigran
diff -urN -X dontdiff linux/Documentation/kernel-parameters.txt
rootfs/Documentation/kernel-parameters.txt
--- linux/Documentation/kernel-parameters.txt Tue Sep 5 21:51:14 2000
+++ rootfs/Documentation/kernel-parameters.txt Mon Dec 18 09:04:06 2000
@@ -473,7 +473,10 @@
ro [KNL] Mount root device read-only on boot.
- root= [KNL] root filesystem.
+ root= [KNL] Mount root filesystem on specified (as hex or
+"/dev/XXX") device.
+
+ rootfs= [KNL] Use filesystem type specified (e.g. rootfs=ext2) for
+root.
+
rw [KNL] Mount root device read-write on boot.
diff -urN -X dontdiff linux/fs/super.c rootfs/fs/super.c
--- linux/fs/super.cTue Dec 12 09:25:22 2000
+++ rootfs/fs/super.c Mon Dec 18 15:03:44 2000
@@ -18,6 +18,7 @@
*Torbjörn Lindh ([EMAIL PROTECTED]), April 14, 1996.
* Added devfs support: Richard Gooch [EMAIL PROTECTED], 13-JAN-1998
* Heavily rewritten for 'one fs - one tree' dcache architecture. AV, Mar 2000
+ * Added rootfs boot param. used by mount_root(): Tigran Aivazian. Dec 2000.
*/
#include linux/config.h
@@ -58,6 +59,12 @@
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
+/* this can be set at boot time, e.g. rootfs=ext2
+ * if set to invalid value or if read_super() fails on the specified
+ * filesystem type then mount_root() will panic
+ */
+static char rootfs[32] __initdata = "";
+
int nr_super_blocks;
int max_super_blocks = NR_SUPER;
LIST_HEAD(super_blocks);
@@ -78,6 +85,17 @@
static struct file_system_type *file_systems;
static rwlock_t file_systems_lock = RW_LOCK_UNLOCKED;
+static int __init rootfs_setup(char *line)
+{
+ int n = strlen(line) + 1;
+
+ if (n 1 n 32)
+ strncpy(rootfs, line, n);
+ return 1;
+}
+
+__setup("rootfs=", rootfs_setup);
+
/* WARNING: This can be used only if we _already_ own a reference */
static void get_filesystem(struct file_system_type *fs)
{
@@ -1579,6 +1597,16 @@
goto mount_it;
}
+ if (*rootfs) {
+ fs_type = get_fs_type(rootfs);
+ if (fs_type) {
+ sb = read_super(ROOT_DEV,bdev,fs_type,root_mountflags,NULL,0);
+ if (sb)
+ goto mount_it;
+ }
+ /* don't try others if type given explicitly, same behaviour as
+mount(8) */
+ goto fail;
+ }
read_lock(file_systems_lock);
for (fs_type = file_systems ; fs_type ; fs_type = fs_type-next) {
if (!(fs_type-fs_flags FS_REQUIRES_DEV))
@@ -1593,6 +1621,7 @@
put_filesystem(fs_type);
}
read_unlock(file_systems_lock);
+fail:
panic("VFS: Unable to mount root %s on %s", *rootfs ? rootfs : "fs",
kdevname(ROOT_DEV));
mount_it:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
On Mon, 18 Dec 2000, Petr Vandrovec wrote: It is possible. But it is hard to track, as it works with serial console, and it is not possible to paint characters to VGA screen, as vgacon uses hardware panning instead of scrolling :-( And if it dies, shift-pageup apparently does not work... And filling whole 32KB with some char does not work, as it changes timing too much... Just disable the problematic printk()s for making tests (you may just undefine APIC_DEBUG in include/asm-i386/apic.h) -- we already know what is going to be printed here. ;-) No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA... Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try if accessing one bus or another changes the behaviour. Yes. I could understand if I had to place bigger udelay() after INIT IPI, as this can cause some specific PIII initialization and Intel says that there should not be any MESI traffic during this init (at least I understand Hmm, weird -- for integrated APICs an INIT IPI is about the same as shutdown apart from the fact an NMI won't wake up a CPU (that might actually be the local APIC not passing NMIs to the CPU in this case, though). it that way). But after startup IPI it should just start executing code... I tried to put 'wbinvd' here and there, but it did not make any change, only udelay() between startup IPI cmd and first printk() did. Hmm, a startup IPI is rather fast so the code just after issuing it may somehow interact with the application's CPU trampoline. But try to disable CONFIG_X86_GOOD_APIC, yet (you may configure for classic Pentium, for example), and see if that changes anything (it shouldn't, but who knows...). I have no idea. I know that board has VT82C694X (rev c4) host and PCI bridge, Just look at the board and search for an I/O APIC chip. ;-) and VT82C686 (rev 22) ISA bridge. I tried to request documentation of 694X from VIA, but I did not heard from them. They have probably some secrets hidden in their hardware... They wan't to keep the competition from being bug-compatible, it would seem... Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
The appended patch fixes the following:
1) We cannot unlock the page in shmem_writepage on ooswap since
page_launder will do this later.
2) We should set the inode number of SYSV segments to the (user)
shmid and not the internal id.
And here additionally is the SYSV detach/destroy logic fixed which
(again) left destroyed shm segments hang around :-(
I also cleaned up the list of included files in ipc/shm.c
Greetings
Christoph
diff -uNr 4-13-3/ipc/shm.c c/ipc/shm.c
--- 4-13-3/ipc/shm.cMon Dec 18 15:08:32 2000
+++ c/ipc/shm.c Mon Dec 18 20:07:21 2000
@@ -15,23 +15,13 @@
*
*/
-#include linux/config.h
-#include linux/module.h
#include linux/malloc.h
#include linux/shm.h
-#include linux/swap.h
-#include linux/smp_lock.h
#include linux/init.h
-#include linux/locks.h
#include linux/file.h
#include linux/mman.h
-#include linux/vmalloc.h
-#include linux/pagemap.h
#include linux/proc_fs.h
-#include linux/highmem.h
-
#include asm/uaccess.h
-#include asm/pgtable.h
#include "util.h"
@@ -109,6 +99,7 @@
BUG();
shp-shm_atim = CURRENT_TIME;
shp-shm_lprid = current-pid;
+ shp-shm_nattch++;
shm_unlock(id);
}
@@ -123,21 +114,14 @@
*
* @shp: struct to free
*
- * It has to be called with shp and shm_ids.sem locked and will
- * release them
+ * It has to be called with shp and shm_ids.sem locked
*/
static void shm_destroy (struct shmid_kernel *shp)
{
- struct file * file = shp-shm_file;
-
- shp-shm_file = NULL;
shm_tot -= (shp-shm_segsz + PAGE_SIZE - 1) PAGE_SHIFT;
- shm_unlock (shp-id);
shm_rmid (shp-id);
+ fput (shp-shm_file);
kfree (shp);
- up (shm_ids.sem);
- /* put the file outside the critical path to prevent recursion */
- fput (file);
}
/*
@@ -158,10 +142,10 @@
BUG();
shp-shm_lprid = current-pid;
shp-shm_dtim = CURRENT_TIME;
- if(shp-shm_flags SHM_DEST
- file_count (file) == 2) /* shp and the vma have the last
- references*/
- return shm_destroy (shp);
+ shp-shm_nattch--;
+ if(shp-shm_nattch == 0
+ shp-shm_flags SHM_DEST)
+ shm_destroy (shp);
shm_unlock(id);
up (shm_ids.sem);
@@ -176,7 +160,7 @@
}
static struct file_operations shm_file_operations = {
- mmap: shm_mmap
+ mmap: shm_mmap
};
static struct vm_operations_struct shm_vm_ops = {
@@ -218,9 +202,10 @@
shp-shm_atim = shp-shm_dtim = 0;
shp-shm_ctim = CURRENT_TIME;
shp-shm_segsz = size;
+ shp-shm_nattch = 0;
shp-id = shm_buildid(id,shp-shm_perm.seq);
shp-shm_file = file;
- file-f_dentry-d_inode-i_ino = id;
+ file-f_dentry-d_inode-i_ino = shp-id;
file-f_op = shm_file_operations;
shm_tot += numpages;
shm_unlock (id);
@@ -370,15 +355,13 @@
struct inode * inode;
shp = shm_get(i);
- if(shp == NULL || shp-shm_file == NULL)
+ if(shp == NULL)
continue;
inode = shp-shm_file-f_dentry-d_inode;
- down (inode-i_sem);
- *rss += inode-i_mapping-nrpages;
spin_lock (inode-u.shmem_i.lock);
+ *rss += inode-i_mapping-nrpages;
*swp += inode-u.shmem_i.swapped;
spin_unlock (inode-u.shmem_i.lock);
- up (inode-i_sem);
}
}
@@ -462,7 +445,7 @@
tbuf.shm_ctime = shp-shm_ctim;
tbuf.shm_cpid = shp-shm_cprid;
tbuf.shm_lpid = shp-shm_lprid;
- tbuf.shm_nattch = file_count (shp-shm_file) - 1;
+ tbuf.shm_nattch = shp-shm_nattch;
shm_unlock(shmid);
if(copy_shmid_to_user (buf, tbuf, version))
return -EFAULT;
@@ -512,13 +495,12 @@
goto out_up;
err = shm_checkid(shp, shmid);
if (err == 0) {
- if (file_count (shp-shm_file) == 1) {
+ if (shp-shm_nattch){
+ shp-shm_flags |= SHM_DEST;
+ /* Do not find it any more */
+ shp-shm_perm.key = IPC_PRIVATE;
+ } else
shm_destroy (shp);
- return 0;
- }
- shp-shm_flags |= SHM_DEST;
- /* Do not find it any more */
- shp-shm_perm.key = IPC_PRIVATE;
}
/* Unlock */
shm_unlock(shmid);
@@ -619,13 +601,23 @@
return -EACCES;
}
file = shp-shm_file;
- get_file (file);
+ shp-shm_nattch++;
2.4.0-test13-pre3 m68k Makefiles
This patch updates the Makefiles used by Linux/m68k to the new Makefile syntax. Additionally I fixed a bug in arch/ppc/amiga/Makefile (for APUS). --- linux-2.4.0-test13-pre3/MakefileMon Dec 18 12:34:22 2000 +++ linux-m68k-test13-pre3/Makefile Mon Dec 18 12:40:50 2000 @@ -159,7 +159,7 @@ DRIVERS-$(CONFIG_PCMCIA_CHRDEV) += drivers/char/pcmcia/pcmcia_char.o DRIVERS-$(CONFIG_DIO) += drivers/dio/dio.a DRIVERS-$(CONFIG_SBUS) += drivers/sbus/sbus_all.o -DRIVERS-$(CONFIG_ZORRO) += drivers/zorro/zorro.a +DRIVERS-$(CONFIG_ZORRO) += drivers/zorro/driver.o DRIVERS-$(CONFIG_FC4) += drivers/fc4/fc4.a DRIVERS-$(CONFIG_ALL_PPC) += drivers/macintosh/macintosh.o DRIVERS-$(CONFIG_MAC) += drivers/macintosh/macintosh.o --- linux-2.4.0-test13-pre3/arch/m68k/amiga/MakefileThu Jul 30 20:08:19 1998 +++ linux-m68k-test13-pre3/arch/m68k/amiga/Makefile Mon Dec 18 12:53:58 2000 @@ -8,11 +8,11 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := amiga.o -O_OBJS := config.o amiints.o cia.o chipram.o amisound.o -OX_OBJS := amiga_ksyms.o -ifdef CONFIG_AMIGA_PCMCIA -O_OBJS := $(O_OBJS) pcmcia.o -endif +export-objs:= amiga_ksyms.o + +obj-y := config.o amiints.o cia.o chipram.o amisound.o amiga_ksyms.o + +obj-$(CONFIG_AMIGA_PCMCIA) += pcmcia.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/apollo/Makefile Tue Feb 8 11:04:33 2000 +++ linux-m68k-test13-pre3/arch/m68k/apollo/MakefileMon Dec 18 12:57:03 2000 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := apollo.o -O_OBJS := config.o dn_ints.o dma.o \ +obj-y := config.o dn_ints.o dma.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/atari/MakefileTue Feb 8 11:04:33 2000 +++ linux-m68k-test13-pre3/arch/m68k/atari/Makefile Mon Dec 18 12:54:27 2000 @@ -8,14 +8,14 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := atari.o -O_OBJS := config.o time.o debug.o atakeyb.o ataints.o stdma.o atasound.o \ -joystick.o stram.o -OX_OBJS := atari_ksyms.o + +export-objs:= atari_ksyms.o + +obj-y := config.o time.o debug.o atakeyb.o ataints.o stdma.o \ + atasound.o joystick.o stram.o atari_ksyms.o ifdef CONFIG_PCI -ifdef CONFIG_HADES -O_OBJS += hades-pci.o -endif +obj-$(CONFIG_HADES)+= hades-pci.o endif include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/bvme6000/Makefile Sat Jun 13 22:14:31 1998 +++ linux-m68k-test13-pre3/arch/m68k/bvme6000/Makefile Mon Dec 18 12:54:32 2000 @@ -8,7 +8,7 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := bvme6000.o -O_OBJS := config.o bvmeints.o rtc.o -#OX_OBJS = ksyms.o + +obj-y := config.o bvmeints.o rtc.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/hp300/MakefileWed Sep 2 18:39:18 1998 +++ linux-m68k-test13-pre3/arch/m68k/hp300/Makefile Mon Dec 18 12:54:43 2000 @@ -8,10 +8,11 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := hp300.o -O_OBJS := ksyms.o config.o ints.o time.o reboot.o -ifdef CONFIG_VT -O_OBJS += hil.o -endif +export-objs:= ksyms.o + +obj-y := ksyms.o config.o ints.o time.o reboot.o + +obj-$(CONFIG_VT) += hil.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/kernel/Makefile Thu Apr 13 21:17:11 2000 +++ linux-m68k-test13-pre3/arch/m68k/kernel/MakefileMon Dec 18 12:54:58 2000 @@ -17,13 +17,13 @@ endif O_TARGET := kernel.o -O_OBJS := entry.o process.o traps.o ints.o signal.o ptrace.o \ - sys_m68k.o time.o semaphore.o -OX_OBJS := setup.o m68k_ksyms.o -ifdef CONFIG_PCI -O_OBJS += bios32.o -endif +export-objs:= setup.o m68k_ksyms.o + +obj-y := entry.o process.o traps.o ints.o signal.o ptrace.o \ + sys_m68k.o time.o semaphore.o setup.o m68k_ksyms.o + +obj-$(CONFIG_PCI) += bios32.o head.o: head.S m68k_defs.h --- linux-2.4.0-test13-pre3/arch/m68k/lib/Makefile Thu Dec 14 12:14:15 2000 +++ linux-m68k-test13-pre3/arch/m68k/lib/Makefile Mon Dec 18 12:55:09 2000 @@ -6,6 +6,8 @@ $(CC) $(AFLAGS) -traditional -c $ -o $@ L_TARGET = lib.a -L_OBJS = ashrdi3.o lshrdi3.o checksum.o memcpy.o memcmp.o memset.o semaphore.o muldi3.o + +obj-y := ashrdi3.o lshrdi3.o checksum.o memcpy.o memcmp.o memset.o \ + semaphore.o muldi3.o include $(TOPDIR)/Rules.make --- linux-2.4.0-test13-pre3/arch/m68k/mac/Makefile Tue Feb 15 21:49:28 2000 +++ linux-m68k-test13-pre3/arch/m68k/mac/Makefile Mon Dec 18 12:55:22 2000 @@ -8,8 +8,10 @@ # Note 2! The CFLAGS definitions are now in the main makefile... O_TARGET := mac.o -OX_OBJS := mac_ksyms.o -O_OBJS := config.o bootparse.o macints.o iop.o via.o oss.o psc.o \ - baboon.o macboing.o debug.o misc.o + +export-objs:= mac_ksyms.o + +obj-y
Re: Startup IPI (was: Re: test13-pre3)
On 18 Dec 00 at 19:44, Maciej W. Rozycki wrote:
No, I'll try. It occured with either AGP (Matrox G200/G400/G450) or
PCI (S3, CL5434) VGA adapter. I did not tried real ISA VGA...
Oops, I've forgotten there exist non-ISA display adapters. ;-) Just try
if accessing one bus or another changes the behaviour.
Uh. It took couple of hours to find it. Just place
{ int i; volatile unsigned short* p = 0xC00B8000; for (i = 0; i 6553600;
i++) { *p; } }(**)
instead of udelay(300) and this loop does not finish. Same for
unsigned long* p. inb/outb(0x3C0) are ok. Writes are OK too. Only
simple fetches from videoram kills it.
When I replaced address with 0xC01B8000 (some cachable memory), it worked
fine. When replaced with 0xC00C8000 (supposedly unused address, but maybe
it is just set as cacheable in chipset), it works too.
Symptoms of lockup are same as hangup in printk() without udelay(300), only
problem is that 'vt_console_print' (*) does not do fetches from videoram, it
does stores only...
Placing this loop before sending startup IPI, or just below udelay(300)
is OK (modulo that this loop takes so long that secondary CPU complains
about no callin received).
I even tried to add:
mov $0xB800,%ax
mov %ax,%ds
movw %ax,0
at the beginning of trampoline.S, and then boot with 'no-scroll', but
character in upper left corner did not change, so secondary CPU probably
even did not start code fetches. That's all I can say until
I put non-AGP card into the box (but I need AGP, so it is not real option).
and VT82C686 (rev 22) ISA bridge. I tried to request documentation
of 694X from VIA, but I did not heard from them. They have probably
some secrets hidden in their hardware...
They wan't to keep the competition from being bug-compatible, it would
seem...
Yeah. Just do not read video memory when another CPU starts. I'll try
disabling cache on both CPUs, maybe it will make some difference, as
secondary CPU should start with caches disabled. But maybe that it is
just broken AGP bus, and nothing else. But until I find what's really
broken on my hardware, I'd like to leave 'udelay(300)' in.
(*) When I was calling directly
vt_console_print(NULL, "Message1\n", 9);
vt_console_print(NULL, "Message2\n", 9);
instead of printk, I got
Message1
Messag0x..0x..0x000x800x..0x800x..0x80...
- wrong text with wrong length, so it probably started fetching garbage
instead of string as soon as second CPU started (no, it did not race due
to missing console_lock; before first printk() secondary CPU should fill
whole screen with letter '2'. It did not).
(**) When I had '*p = i; *p' in loop, from visual inspection it was
dying in range i=0x1380-0x13FF (blue background, cyan letter with diacritics).
End of guessing.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
Yeah. Just do not read video memory when another CPU starts. I'll try disabling cache on both CPUs, maybe it will make some difference, as secondary CPU should start with caches disabled. But maybe that it is just broken AGP bus, and nothing else. But until I find what's really broken on my hardware, I'd like to leave 'udelay(300)' in. In the case where it boots does it also report mismatched MTRRs ?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
Olaf Titz wrote: In article [EMAIL PROTECTED] you write: [J Sloan] kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range ... Those symbols are rather generic and rather important. Sounds like a generic module problem. Do other modules load? Yes, rtl8139, emu10k are loaded and working fine. Does your kernel use MODVERSIONS? Yes, I have CONFIG_MODVERSIONS=y (This module apparently doesn't.) Are you using a recent version of modutils? # insmod -V insmod version 2.3.21 ... The most important question: Did you run "make dep" after doing the patch? Yes, after the patch, it was, as always: make clean make menuconfig make dep bzlilo modules modules_install Same problem with 2.4.0-test13-pre3-ac1 on my Linux workstation at the office, where the token ring driver fails as well (olympic.o) BTW, in my experience to date with kernels from 2.3.36 up to 2.4.0-test-12 it has all worked well. jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3
List: linux-kernel Subject: Re: test13-pre3 woes From: Peter Samuelson [EMAIL PROTECTED] Date: 2000-12-18 9:19:13 [Download message RAW] [J Sloan] The module now compiles and gets installed - Unfortunately, attempting to load it does not go well: kernel/drivers/char/drm/tdfx.o: unresolved symbol remap_page_range kernel/drivers/char/drm/tdfx.o: unresolved symbol __wake_up kernel/drivers/char/drm/tdfx.o: unresolved symbol mtrr_add kernel/drivers/char/drm/tdfx.o: unresolved symbol __generic_copy_from_user kernel/drivers/char/drm/tdfx.o: unresolved symbol schedule kernel/drivers/char/drm/tdfx.o: unresolved symbol kmalloc kernel/drivers/char/drm/tdfx.o: unresolved symbol si_meminfo Those symbols are rather generic and rather important. Sounds like a generic module problem. Do other modules load? Does your kernel use MODVERSIONS? (This module apparently doesn't.) Are you using a recent version of modutils? Puzzled. Maybe Keith Owens knows something. Peter I got this, too. The one liner send here on lkm seems to be not enough. Even Alan's ac1/2 did not do the trick. The 'new' Linux makefile changes brake this stuff. It works before these changes. So Rik any comments? Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Startup IPI (was: Re: test13-pre3)
Pardon me for not fully groking the issues here and possibly coming to a wrong conclusion, but this has to do with SMP systems crashing at APIC init time, just before penguin display (with fbcon at least)? If so, I have a board that does this with certain cache settings made in the BIOS. It's a 430HX chipset with two Pentium MMX 200s installed, *ancient* BIOS. -- Ferret - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.0-test13-pre3: Makefile problem in drivers/video
[Norbert Breun] > The problem is, there should be a directory "media" under > /lib/modules/2.4.0-test12.old/kernel/drivers/ and this is missing in > test13pre2 and test13pre3. The modules are not built. Does this help? I think it's right. Peter diff -urk.orig 2.4.0test13pre3/drivers/media/Makefile --- 2.4.0test13pre3/drivers/media/Makefile.orig Sat Dec 16 06:18:16 2000 +++ 2.4.0test13pre3/drivers/media/Makefile Mon Dec 18 01:32:34 2000 @@ -10,6 +10,7 @@ # subdir-y := video radio +subdir-m := video radio O_TARGET := media.o obj-y:= $(join $(subdir-y),$(subdir-y:%=/%.o)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test13-pre3: Makefile problem in drivers/video
Peter, you may be right there is no module "video.o". The problem is, there should be a directory "media" under /lib/modules/2.4.0-test12.old/kernel/drivers/ and this is missing in test13pre2 and test13pre3. The modules are not built. kind regards Norbert On Monday 18 December 2000 07:11, Peter Samuelson wrote: > [Mikael Djurfeldt] > > > When trying to build video.o as a module, video.o doesn't get copied > > to /lib/modules/* during installation. > > There is no video.o module. If video.o is built at all, it is linked > into the vmlinux image directly. The modules in that directory will be > atyfb.o, tdfxfb.o and about 800 others. > > Peter > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test13-pre3: Makefile problem in drivers/video
[Mikael Djurfeldt] > When trying to build video.o as a module, video.o doesn't get copied > to /lib/modules/* during installation. There is no video.o module. If video.o is built at all, it is linked into the vmlinux image directly. The modules in that directory will be atyfb.o, tdfxfb.o and about 800 others. Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre3 woes
On Mon, 18 Dec 2000, J Sloan wrote: > Similar problem here - with CONFIG_DRM_TDFX=m > I have not gotten a tdfx.o module complied since the > start of the test13-pre series... > > So no quake 3 arena unless I want to play at < 1 fps... > Does this patch fix your problem? --- test13-pre3/drivers/char/Makefile Mon Dec 18 01:21:31 2000 +++ linux/drivers/char/Makefile Mon Dec 18 06:58:06 2000 @@ -16,6 +16,8 @@ O_TARGET := char.o +mod-subdirs := drm + obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o # All of the (potential) objects that export symbols. -- Niels Kristian Bech Jensen -- [EMAIL PROTECTED] -- http://www.image.dk/~nkbj/ --->> Stop software piracy --- use free software! <<--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
