Re: NCPFS, anyone?
From: IvanK. [EMAIL PROTECTED] Date: Thu, 3 Oct 2002 19:12:10 -0400 I've compiled many times 2.4.19 with 3.1 cross-compiled for sparc64-linux and so far had had no problem (except not being able to compile framebuffer support). Should I continue using it (if it ain't broke, don't fix it) or should I compile egcs64? If it doesn't break for you, that's great. Keep using it :-)
RE : 2.5.40 on Sunblade 100 (was Re: NCPFS, anyone?)
Hi, However, I think Dave is making it a point to get gcc-3.2 able to build kernels. I compiled a 2.4.19 kernel with gcc-3.2.1 on my Blade 100 and it seems to work fine for the moment. Olivier Hochreutiner [EMAIL PROTECTED] -Message d'origine- De : Ben Collins [mailto:[EMAIL PROTECTED] Envoyé : jeudi, 3. octobre 2002 03:01 À : Roy Bixler Cc : David S. Miller; debian-sparc@lists.debian.org; sparclinux@vger.kernel.org Objet : Re: 2.5.40 on Sunblade 100 (was Re: NCPFS, anyone?) I thought GCC 3.1 and above are OK for compiling kernels on Ultrasparc. I also thought the IDE drivers were from the 2.4 series and should be stable. Will I have to eat my words there too? egcs64 has always been the suggested way to compile kernels from ultrasparc. Nothing else has ever been suggested or supported up to this point. However, I think Dave is making it a point to get gcc-3.2 able to build kernels. As for 2.5.40 on Blade100, I just got a kernel built on mine, and I'm about to reboot myself. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NCPFS, anyone?
Dave, I've compiled many times 2.4.19 with 3.1 cross-compiled for sparc64-linux and so far had had no problem (except not being able to compile framebuffer support). Should I continue using it (if it ain't broke, don't fix it) or should I compile egcs64? Thanks, IvanK. [EMAIL PROTECTED] ivan]$ /usr/sparc64-linux/bin/sparc64-linux-gcc --version sparc64-linux-gcc (GCC) 3.1 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On Wednesday 02 October 2002 07:48 pm, David S. Miller wrote: From: Roy Bixler [EMAIL PROTECTED] Date: Wed, 2 Oct 2002 12:44:46 -0500 Any suggestions for getting 2.5.x kernels running are appreicated. Otherwise, I'll have to try your patches on a 2.4 kernel. Don't use gcc-3.2 to build the kernel. It has known problems. Take the egcs64 package from the stable debian release and use that. - To unsubscribe from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NCPFS, anyone?
On Mon, Sep 30, 2002 at 03:48:22PM +0200, Petr Vandrovec wrote: Hi Roy, ncpfs related sparc fixes are now in Linus kernels (2.5.x), and DaveM also told me that he applied patches to his 2.4.x tree, so they should arrive to Marcelo soon too. If you'll download ncpfs-2.2.0.19.8.tar.gz from ftp://platan.vc.cvut.cz/private/ncpfs (or http://platan.vc.cvut.cz/ftp/private/ncpfs), everything should work - except ipx_* tools - I did not managed to create wrappers around IPX ioctls yet. But you should be able to get it to work over IP. It passed all test I tried, but it is easy possible that I forgot something - I did not tried symlinks, device nodes, pipes and other suspicious things. If you'll find any problem, tell me. I have now ultra sparc under the table, so it should be easy for me to recreate and fix problem. Best regards, Petr Vandrovec [EMAIL PROTECTED] I've been trying to get the 2.5 kernels to run on the Sunblade 100, but I haven't had any luck. Around 2.5.37, I was at least able to compile them (with perhaps some trivial patch or other) but it would never boot. That is, I get a SILO prompt, select the 2.5.latest kernel, it says (roughly) Remapping kernel ... done, then it hangs at Booting Linux ... I am using the Debian sid version of GCC 3.2 to compile the kernel. In my latest attempt, I changed the 2.5.40 Makefile to use the sparc64-linux-gcc compiler which I used to successfully compile 2.4.19. This time, the boot got past the 'Booting Linux' but perhaps my options are not set right because, after getting the black screen, the characters were unreadable. Linux eventually hung but, because of the unreadable font, I couldn't say where. Any suggestions for getting 2.5.x kernels running are appreicated. Otherwise, I'll have to try your patches on a 2.4 kernel. Thanks for all you work and I look forward to testing. -- Roy Bixler [EMAIL PROTECTED]
RE: NCPFS, anyone?
In my latest attempt, I changed the 2.5.40 Makefile to use the sparc64-linux-gcc compiler which I used to successfully compile 2.4.19. This time, the boot got past the 'Booting Linux' but perhaps my options are not set right because, after getting the black screen, the characters were unreadable. The FB layer has been undergoing a lot of changes. Not sure what Vid card the blade100 has, but my ati mach64 based one in the Ultra5 exhibited the same behavior. At one point, I was actually looking at this, and James Simmons had some modifications to his bk tree at http://fbdev.bkbits.net/fbdev-2.5 alas, my job has mostly shifted here, and I have been unable to get back to looking into this for some time to see if his updates worked. YMMV. Linux eventually hung but, because of the unreadable font, I couldn't say where. Also, is it IDE based? I was definitely having problems with IDE in 2.5 after 2.5.13. Not sure of the status of that yet either. Maybe you can turn off framebuffer support, and see how far it goes? Any suggestions for getting 2.5.x kernels running are appreicated. Otherwise, I'll have to try your patches on a 2.4 kernel. Thanks for all you work and I look forward to testing.
Re: NCPFS, anyone?
On Wed, Oct 02, 2002 at 01:07:25PM -0500, Holzrichter, Bruce wrote: In my latest attempt, I changed the 2.5.40 Makefile to use the sparc64-linux-gcc compiler which I used to successfully compile 2.4.19. This time, the boot got past the 'Booting Linux' but perhaps my options are not set right because, after getting the black screen, the characters were unreadable. The FB layer has been undergoing a lot of changes. Not sure what Vid card the blade100 has, but my ati mach64 based one in the Ultra5 exhibited the same behavior. At one point, I was actually looking at this, and James Simmons had some modifications to his bk tree at http://fbdev.bkbits.net/fbdev-2.5 alas, my job has mostly shifted here, and I have been unable to get back to looking into this for some time to see if his updates worked. YMMV. Yes, it's got an ATI-based video card. Here is what the 'dmesg' output from the 2.4.19 kernel says: atyfb: 3D RAGE (XL) [0x4752 rev 0x27] 8M SDRAM, 29.498928 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK Console: switching to colour frame buffer device 160x64 fb0: ATY Mach64 frame buffer device on PCI Here's the snippet from my current .config file: # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set CONFIG_FB_ATY=y # CONFIG_FB_ATY_GX is not set CONFIG_FB_ATY_CT=y # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_SBUS is not set CONFIG_FB_PCI=y CONFIG_FB_ATY=y CONFIG_FB_ATY_CT=y # CONFIG_FB_VIRTUAL is not set # CONFIG_FBCON_ADVANCED is not set CONFIG_FBCON_CFB24=y CONFIG_FBCON_ACCEL=y # CONFIG_FBCON_FONTWIDTH8_ONLY is not set # CONFIG_FONT_SUN8x16 is not set CONFIG_FONT_SUN12x22=y # CONFIG_FBCON_FONTS is not set Note here that I tried the 'CONFIG_FONT_SUN12x22=y' option, but I only found that gave me larger unreadable characters. :-/ Linux eventually hung but, because of the unreadable font, I couldn't say where. Also, is it IDE based? I was definitely having problems with IDE in 2.5 after 2.5.13. Not sure of the status of that yet either. Yes, it is IDE-based. Last I heard, Marcin Daleki stopped maintaining the 2.5 IDE code and the 2.5 series now uses the IDE logic from the 2.4 series. Accordingly, IDE in 2.5 is reputed to be stable as it is in the 2.4 kernels. Maybe you can turn off framebuffer support, and see how far it goes? I didn't realise I could do that. I thought the frame buffer is mandatory. Or is it only mandatory if I want to use X on it? thx, R.
Re: NCPFS, anyone?
Yes, it is IDE-based. Last I heard, Marcin Daleki stopped maintaining the 2.5 IDE code and the 2.5 series now uses the IDE logic from the 2.4 series. Accordingly, IDE in 2.5 is reputed to be stable as it is in the 2.4 kernels. Maybe you can turn off framebuffer support, and see how far it goes? I didn't realise I could do that. I thought the frame buffer is mandatory. Or is it only mandatory if I want to use X on it? As a matter of fact I could never compile 2.4.19 or 2.5.3x with framebuffer support -- my compile always ended with an error. So I'm running my blade100 bufferless. It works and I like the sunos-like black text on white background more than the white-on-black that the framebuffer uses. Any way to tell the framebuffer to reverse fg and bg? I guess I ought to RTFM, but since I have the podium :-) Thanks, IvanK.
Re: 2.5.40 on Sunblade 100 (was Re: NCPFS, anyone?)
I thought GCC 3.1 and above are OK for compiling kernels on Ultrasparc. I also thought the IDE drivers were from the 2.4 series and should be stable. Will I have to eat my words there too? egcs64 has always been the suggested way to compile kernels from ultrasparc. Nothing else has ever been suggested or supported up to this point. However, I think Dave is making it a point to get gcc-3.2 able to build kernels. As for 2.5.40 on Blade100, I just got a kernel built on mine, and I'm about to reboot myself. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: NCPFS, anyone?
On Thu, 5 Sep 2002, Roy Bixler wrote: I do have 'ncpfs' compiled into the kernel as a module. The really bizarre thing about this is that the 'mount' version appears to be the same (2.11) on both the old '386 box and the new Sparc. Ideas? I should have also noted that I am using a stock 2.4.19 kernel. I tried several 2.4.x kernels because of some other problems. Anywhere between 2.4.9 and 2.4.16 NCPFS stopped working. (Note I'm not really sure wether 2.4.9 really worked - but I definitely had my Sparc running with NCPFS - perhaps it was a 2.2.x series kernel.) Sorry - I was to busy with other stuff to track down the problem but I can commit that NCPFS is currently broken on Sparc. Kind regards Andreas.
Re: NCPFS, anyone?
On 5 Sep 02 at 19:45, Roy Bixler wrote: On Thu, Sep 05, 2002 at 05:53:26PM -0500, Roy Bixler wrote: Has anyone gotten NCPFS mounts to work in Woody? Actually, I have but only on my old '386 box. However, on the Sparc, I get this: # ncpmount -S server -U rcb -A server /mnt Logging into SERVER as RCB Password: ncpmount: Invalid argument in mount(2) A 'dmesg' command shows the following: ncp_read_super: kernel requires mount version 3 It should work, but only if you are using sparc binary on sparc kernel, or sparc64 binary on sparc64 kernel, otherwise sizeof(int), sizeof(long), sizeof(__kernel_uid_t) and other may differ between kernel and user. I have patch to ncpfs kernel (2.5.x) to pass mount options through ASCII string, if you are interested. But before you'll try that, try first ncpmount -S server -U rcb -A server -3 /mnt and ncpmount -S server -U rcb -A server -4 /mnt. 2.4.x kernels should use mount version 4 (which allows for 32bit uid/gid), but if you'll look at arch/sparc64/kernel/sys_sparc32.c, do_ncp_super_data_conv, you'll find that this function (1) does not check version at all, (2) works only with -3 version, and (3) I do not see where this function actually copies unchanged members: version, ncp_fd, time_out, retry_count and flags... But if you'll rebuild ncpmount as a 64bit binary, problems should disappear without need to fix kernel. Petr Vandrovec [EMAIL PROTECTED]
Re: NCPFS, anyone?
On Fri, 6 Sep 2002, Petr Vandrovec wrote: It should work, but only if you are using sparc binary on sparc kernel, or sparc64 binary on sparc64 kernel, otherwise sizeof(int), sizeof(long), sizeof(__kernel_uid_t) and other may differ between kernel and user. I have patch to ncpfs kernel (2.5.x) to pass mount options through ASCII string, if you are interested. bse:~/tmp uname -a Linux bse 2.4.19-pre9 #1 SMP Mon Jun 3 11:47:28 CEST 2002 sparc64 unknown I have no idea how to specify the right user client on my Debian/Woody system. Any idea? But before you'll try that, try first ncpmount -S server -U rcb -A server -3 /mnt and bse:~/tmp ncpmount -S WRS1 -U TilleA.USER.WR.RKI -A 10.15.140.41 -3 mnt Logging into WRS1 as TILLEA.USER.WR.RKI Password: ncpmount: Invalid argument in mount(2) ncpmount -S server -U rcb -A server -4 /mnt. bse:~/tmp ncpmount -S WRS1 -U TilleA.USER.WR.RKI -A 10.15.140.41 -4 mnt Logging into WRS1 as TILLEA.USER.WR.RKI Password: ncpmount: Invalid argument in mount(2) I'm not sure about the use of -A option because I never needed this on i386 hardware 2.4.x kernels should use mount version 4 (which allows for 32bit uid/gid), but if you'll look at arch/sparc64/kernel/sys_sparc32.c, do_ncp_super_data_conv, you'll find that this function (1) does not check version at all, (2) works only with -3 version, and (3) I do not see where this function actually copies unchanged members: version, ncp_fd, time_out, retry_count and flags... But if you'll rebuild ncpmount as a 64bit binary, problems should disappear without need to fix kernel. Might be I'll do that. But I doubt that it will help much for my special case because the machine in question will leave the Novell environment to fullfill a different job. So it would just for academic reason ... Kind regards Andreas.
Re: NCPFS, anyone?
On Fri, Sep 06, 2002 at 11:59:55AM +0200, Petr Vandrovec wrote: On 5 Sep 02 at 19:45, Roy Bixler wrote: On Thu, Sep 05, 2002 at 05:53:26PM -0500, Roy Bixler wrote: Has anyone gotten NCPFS mounts to work in Woody? Actually, I have but only on my old '386 box. However, on the Sparc, I get this: # ncpmount -S server -U rcb -A server /mnt Logging into SERVER as RCB Password: ncpmount: Invalid argument in mount(2) A 'dmesg' command shows the following: ncp_read_super: kernel requires mount version 3 It should work, but only if you are using sparc binary on sparc kernel, or sparc64 binary on sparc64 kernel, otherwise sizeof(int), sizeof(long), sizeof(__kernel_uid_t) and other may differ between kernel and user. That's probably it - the machine has an Ultrasparc IIe processor but, as far as I understand about the Debian Woody distribution, the binaries are all built in 32-bit mode. I have patch to ncpfs kernel (2.5.x) to pass mount options through ASCII string, if you are interested. But before you'll try that, try first ncpmount -S server -U rcb -A server -3 /mnt and ncpmount -S server -U rcb -A server -4 /mnt. 2.4.x kernels should use mount version 4 (which allows for 32bit uid/gid), but if you'll look at arch/sparc64/kernel/sys_sparc32.c, do_ncp_super_data_conv, you'll find that this function (1) does not check version at all, (2) works only with -3 version, and (3) I do not see where this function actually copies unchanged members: version, ncp_fd, time_out, retry_count and flags... The only thing that changes if I execute those two commands is, with the former, I no longer get the warning about ncp_read_super: kernel requires mount version 3. Otherwise, they both complain about ncpmount: Invalid argument in mount(2). But if you'll rebuild ncpmount as a 64bit binary, problems should disappear without need to fix kernel. I used gcc-3.0 to build a 64-bit 'ncpmount' binary and I get a 'Segmentation fault' when I try to execute it. I would be willing to try kernel patches, especially in a 2.4.x kernel. I'll even experiment with 2.5 kernel patches if I can get one of those to build and it is stable enough. Thanks, Roy Bixler [EMAIL PROTECTED]
Re: NCPFS, anyone?
On Fri, Sep 06, 2002 at 06:22:48PM +0200, Petr Vandrovec wrote: Patch below is for latest kernel I have unpacked here. I hope that it applies to the released 2.4.19 too... It compiles, but it is everything I can tell about it. It is entirely possible that after you'll get Netware volume mounted, ioctl mapping layer will need some tweaking too. You'll see, if nwdir will not work, there is something wrong... I tried the patch on kernel 2.4.19, but now I get: $ ncpmount -S server -U rcb -A server /mnt ncpmount: Invalid argument attempt to open mount point and 'dmesg' reports: Sep 6 12:39:51 mymach kernel: sys32_ioctl(ncpmount:805): Unknown cmd fd(4) cmd(c0246e04) arg(0004b1f4) Sep 6 12:39:51 mymach kernel: sys32_ioctl(ncpmount:805): Unknown cmd fd(4) cmd(c0286e04) arg(e398) Thanks, Roy Bixler [EMAIL PROTECTED]
NCPFS, anyone?
Has anyone gotten NCPFS mounts to work in Woody? Actually, I have but only on my old '386 box. However, on the Sparc, I get this: # ncpmount -S server -U rcb -A server /mnt Logging into SERVER as RCB Password: ncpmount: Invalid argument in mount(2) A 'dmesg' command shows the following: ncp_read_super: kernel requires mount version 3 I do have 'ncpfs' compiled into the kernel as a module. The really bizarre thing about this is that the 'mount' version appears to be the same (2.11) on both the old '386 box and the new Sparc. Ideas? Thanks, -- Roy Bixler [EMAIL PROTECTED]
Re: NCPFS, anyone?
On Thu, Sep 05, 2002 at 05:53:26PM -0500, Roy Bixler wrote: Has anyone gotten NCPFS mounts to work in Woody? Actually, I have but only on my old '386 box. However, on the Sparc, I get this: # ncpmount -S server -U rcb -A server /mnt Logging into SERVER as RCB Password: ncpmount: Invalid argument in mount(2) A 'dmesg' command shows the following: ncp_read_super: kernel requires mount version 3 I do have 'ncpfs' compiled into the kernel as a module. The really bizarre thing about this is that the 'mount' version appears to be the same (2.11) on both the old '386 box and the new Sparc. Ideas? I should have also noted that I am using a stock 2.4.19 kernel. TIA, R.
