Re: 2.4.0 on sparc64 build problems
* Horst von Brand <[EMAIL PROTECTED]> [010105 09:24]: > Sun Ultra 1, RH 6.2 + updates (+ local hacks) > > Building modules: > > In drivers/sbus/audio: > > amd7930.c:113: ../../isdn/hisax/foreign.h: No such file or directory > amd7930.c:1159: warning: function declaration isn't a prototype > amd7930.c: In function `amd7930_dxmit': > amd7930.c:1266: warning: assignment from incompatible pointer type > amd7930.c: In function `amd7930_drecv': > amd7930.c:1312: warning: assignment from incompatible pointer type > amd7930.c: At top level: > amd7930.c:1486: variable `amd7930_foreign_interface' has initializer but >incomplete type > [Ad nauseam] > > dbri.c:67: ../../isdn/hisax/foreign.h: No such file or directory > [More or less the same junk as above] I'm wondering why building those drivers are options at all on sparc64 since none of the sparc64 machines (that I know of) currently available have anything other than the cs4231 or no audio support. Basically, those two should be removed from the config options for sparc64... and in the meantime, you should build without 'em. :) - 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: linux-2.4.0 SMP does not compile on sparc32
* Felix von Leitner <[EMAIL PROTECTED]> [001017 09:34]: > This is the error message (yes, I am cross compiling): > > mm/mm.o: In function `smp_call_function_all_cpus': > mm/mm.o(.text+0xb194): undefined reference to `smp_call_function' > make: *** [vmlinux] Error 1 > > smp_call_function is defined in arch/sparc64/kernel/smp.c but not in > arch/sparc/kernel/smp.c :-( That was fixed in the vger cvs tree about 2 weeks ago... that has possibly not yet been merged back into the mainline. Even then, your best bet (if you're messing with SPARC/Linux) would be to use the cvs tree (see http://vger.samba.org/). Good luck. :) - 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: aaaah! complete lockup 2.4.0-test9 SPARC32
* Dr. Kelsey Hudson <[EMAIL PROTECTED]> [001004 19:06]: > Machine: > SPARCstation 20, 1xTMS390Z55 50MHz SuperSPARC II w/1MB SuperCACHE > 48MB RAM, about 9G total disk space spanned over 3 drives, TGX... Ok, if you wanna try it, snarf from the vger cvs tree or just change DBRI_NO_INTS in drivers/sbus/audio/dbri.h from 2 to 1... see if the driver works for you. It works on my SS10, and is a temporary work-around until it's properly fixed. - 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: aaaah! complete lockup 2.4.0-test9 SPARC32
* Anton Blanchard <[EMAIL PROTECTED]> [001004 21:31]:
> > I just had my box completely lock up under 2.4.0-test9. I had insmodded
> > the dbri.o audio driver, which for some reason was refusing to work, at
> > all. So I rmmodded it, and at that point, the screen flickered once and
> > wham, complete lockup, nothing responds at all, no network, no SysRQ,
> > anything...Not even an oops printed to the screen.
> >
> > Machine:
> > SPARCstation 20, 1xTMS390Z55 50MHz SuperSPARC II w/1MB SuperCACHE
> > 48MB RAM, about 9G total disk space spanned over 3 drives, TGX...
>
> Short answer: don't use the dbri module :)
>
> It is buggy and requires someone to fix it.
Well, while I had Pete Zaitcev over the other day, we looked into
the problem a bit. I captured the oopses and ran it through ksymoops
and got this stack trace...
Trace; f001c6ec
Trace; f0010c88
Trace; f001ed28
Trace; f0016d5c <_sparc_free_io+2c/50>
Trace; f0016b18
Trace; f0016b88
Trace; fe311380 <[dbri]dbri_detach+1c/48>
Trace; fe313e8c <[dbri]cleanup_module+30/67>
Working our way up, Pete noticed that _sparc_free_io() wasn't aligning
plen properly... problem solved.
While we were there, we noticed a few more problems in the file (misuse
of a #define, and poor renaming of copied code).
At this point, the dbri driver is properly loadable and unloadable...
now it just needs to be fixed... the patch follows...
Index: arch/sparc/kernel/ioport.c
===
RCS file: /cvs/linux/arch/sparc/kernel/ioport.c,v
retrieving revision 1.39
diff -u -r1.39 ioport.c
--- arch/sparc/kernel/ioport.c 2000/06/20 01:10:00 1.39
+++ arch/sparc/kernel/ioport.c 2000/10/09 07:55:15
@@ -244,6 +244,7 @@
unsigned long plen;
plen = res->end - res->start + 1;
+ plen = (plen + PAGE_SIZE-1) & PAGE_MASK;
while (plen != 0) {
plen -= PAGE_SIZE;
(*_sparc_unmapioaddr)(res->start + plen);
@@ -323,7 +324,7 @@
return;
}
- if (((unsigned long)p & (PAGE_MASK-1)) != 0) {
+ if (((unsigned long)p & (PAGE_SIZE-1)) != 0) {
printk("sbus_free_consistent: unaligned va %p\n", p);
return;
}
@@ -496,7 +497,7 @@
if ((res = kmalloc(sizeof(struct resource), GFP_KERNEL)) == NULL) {
free_pages(va, order);
- printk("sbus_alloc_consistent: no core\n");
+ printk("pci_alloc_consistent: no core\n");
return NULL;
}
memset((char*)res, 0, sizeof(struct resource));
@@ -546,18 +547,18 @@
if ((res = _sparc_find_resource(&_sparc_dvma,
(unsigned long)p)) == NULL) {
- printk("sbus_free_consistent: cannot free %p\n", p);
+ printk("pci_free_consistent: cannot free %p\n", p);
return;
}
- if (((unsigned long)p & (PAGE_MASK-1)) != 0) {
- printk("sbus_free_consistent: unaligned va %p\n", p);
+ if (((unsigned long)p & (PAGE_SIZE-1)) != 0) {
+ printk("pci_free_consistent: unaligned va %p\n", p);
return;
}
n = (n + PAGE_SIZE-1) & PAGE_MASK;
if ((res->end-res->start)+1 != n) {
- printk("sbus_free_consistent: region 0x%lx asked 0x%lx\n",
+ printk("pci_free_consistent: region 0x%lx asked 0x%lx\n",
(long)((res->end-res->start)+1), (long)n);
return;
}
-
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-test9-pre8 on SPARC build failure
* Horst von Brand <[EMAIL PROTECTED]> [001002 10:35]: > This PCI stuff was discussed before... > > pcic.c: At top level: > pcic.c:39: redefinition of `pcibios_present' > /usr/src/linux-2.4.0-test/include/linux/pci.h:562: `pcibios_present' previously >defined here > make[1]: *** [pcic.o] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.4.0-test/arch/sparc/kernel' > make: *** [_dir_arch/sparc/kernel] Error 2 That fix is already in the vger sparc cvs kernel tree... just remove the definition of pcibios_present() in pcic.c and you should be fine... - 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: problem with cscope and 2.4-test8 source file
* Mark Salisbury <[EMAIL PROTECTED]> [000918 07:32]:
> I use cscope version 13.7 (on solaris 2.6)
There is an open sourced version of cscope released under a BSD license at
http://cscope.sourceforge.net/ ...
> the source file linux/fs/hpfs/super.c
>
> from kernel version 2.4-test8 causes cscope to core dump during the database
> generation phase.
>
> the problem is the extremely long printk() string starting on line 280 in the
> function static inline void hpfs_help(void){}
I just tried it with the open sourced cscope, and it works on that line
just fine. It (the cscope) still needs a little work in some areas, but
it seems fairly decent to me.
> simply breaking up this printk up into several smaller printk's solves the
> problem.
You can submit a kernel patch if you think it'll get accepted... it's
a trivial enough hack... but no guarantees.
> I guess this is only a problem if you use cscope, but I thought you all would
> like to know..
Try using the open source cscope... this isn't a bug there, and if you
do run into any, you can always email me (or submit to cscope's
sourceforge site) patches to it.
Good luck. :)
-
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] sr.c 2.4.0-test8-pre5 breakage
* Jens Axboe <[EMAIL PROTECTED]> [000906 06:32]: > On Wed, Sep 06 2000, Arnaldo Carvalho de Melo wrote: > > Em Wed, Sep 06, 2000 at 02:42:02AM -0700, Joshua Uziel escreveu: > > > Heya acme... seems you fixed the sr.c driver a bit too much and > > > killed an #ifdef MODULE that was needed if you build without > > > > Nope, I didn't touched this, Jens? > > Yeah, this is my booboo not Arnaldo's. Cool... at least you guys know now... acme - I thought it was you because I saw the change occur with your comment at the top (and it seemed like cleanup). :) - 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] sr.c 2.4.0-test8-pre5 breakage
Heya acme... seems you fixed the sr.c driver a bit too much and
killed an #ifdef MODULE that was needed if you build without
modules (as I do on some of my SPARCs)... this change was made
in 2.4.0-test8-pre5...
drivers/scsi/scsidrv.o: In function `init_sr':
drivers/scsi/scsidrv.o(.text+0x1ece8): undefined reference to
`scsi_register_module'
drivers/scsi/scsidrv.o: In function `exit_sr':
drivers/scsi/scsidrv.o(.text+0x1ed08): undefined reference to
`scsi_unregister_module'
make: *** [vmlinux] Error 1
Patch is as follows:
--- linux/drivers/scsi/sr.c Wed Sep 6 02:38:24 2000
+++ linux-test/drivers/scsi/sr.cWed Sep 6 02:37:18 2000
@@ -848,6 +848,8 @@
return;
}
+#ifdef MODULE
+
int init_sr(void)
{
sr_template.module = THIS_MODULE;
@@ -880,3 +882,5 @@
module_init(init_sr);
module_exit(exit_sr);
+
+#endif /* MODULE */
-
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/
