Re: 2.4.0 on sparc64 build problems

2001-01-05 Thread Joshua Uziel

* 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: 2.4.0 on sparc64 build problems

2001-01-05 Thread Joshua Uziel

* 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

2000-10-17 Thread Joshua Uziel

* 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: linux-2.4.0 SMP does not compile on sparc32

2000-10-17 Thread Joshua Uziel

* 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

2000-10-12 Thread Joshua Uziel

* 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

2000-10-12 Thread Joshua Uziel

* 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

2000-10-09 Thread Joshua Uziel

* 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: aaaah! complete lockup 2.4.0-test9 SPARC32

2000-10-09 Thread Joshua Uziel

* 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 do_sparc_fault+308/3ac
Trace; f0010c88 srmmu_fault+58/68
Trace; f001ed28 srmmu_unmapioaddr+a4/b4
Trace; f0016d5c _sparc_free_io+2c/50
Trace; f0016b18 iounmap+34/78
Trace; f0016b88 sbus_iounmap+4/14
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

2000-10-03 Thread Joshua Uziel

* 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: 2.4.0-test9-pre8 on SPARC build failure

2000-10-03 Thread Joshua Uziel

* 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

2000-09-18 Thread Joshua Uziel

* 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

2000-09-06 Thread Joshua Uziel

* 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

2000-09-06 Thread Joshua Uziel

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/



[PATCH] sr.c 2.4.0-test8-pre5 breakage

2000-09-06 Thread Joshua Uziel

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/



Re: [PATCH] sr.c 2.4.0-test8-pre5 breakage

2000-09-06 Thread Joshua Uziel

* 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/