NFS rpc.lockd bug in nfs client mode - patch attached.
All, I'm running -current on my main box, NFS mounting home directories from my -stable box. The -current box is configured as an NFS client only as it does not serve anything. The -stable box is configured as an NFS server only. In this configuration, running rpc.statd and rpc.lockd on both boxes (manually started on the -current box as it does not support rpc.lockd statd via /etc/rc in nfs client mode[1]), rpc.lockd core dumps reliably on the -current client when unlocking a file on the server. I have tracked this down as a problem with too few parameters being passed to lock_answer (file kern.c). The attached patch fixes the problem for me by bringing the parameters in line with the other calls to lock_answer. Can someone with commit priviledges please review the patch and commit it if it does the right thing? Thanks, Timo [1] I can supply a rough patch to fix this problem, but I'm not happy with it. If someone is interested in reviewing the patch, please drop me an email and I'll get it off to you. --- lock_proc.c.old Sun Oct 14 19:36:35 2001 +++ lock_proc.c Sun Nov 11 11:57:35 2001 @@ -763,7 +763,7 @@ if (debug_level) log_from_addr(nlm_unlock_res, rqstp); - lock_answer(arg-cookie, arg-stat.stat, NLM_VERS); + lock_answer(-1, arg-cookie, arg-stat.stat, NULL, NLM_VERS); return (NULL); }
Internal USR I-modem current?
All, I recently got my hands on an internal Courier I-Modem. Figuring it was very similar to a regular PnP modem I dropped it in my -current box and it showed up as 'unknown'. Hmm. Further inspection of isa/sio.c revealed that the modem's pnp id was not in the table so I added it and rebuilt the kernel. Still no joy, card shows up as unknown again. Tried to configure the ard for the example sio2 as listed in generic but this resulted in 'irq 5 not in allowable map of irqs 0' (sorry, that is a transcription, the -current box is currently down). However configuring the card to sio1 (after disabling on-board sio1) has it probed correctly. Any ideas where I need to look to get this card configured by the PnP mechanism? Thanks, Timo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please check missing logical IDs for SB
On Wed, Dec 01, 1999 at 10:18:26AM +0900, Seigo Tanimura wrote: If you have an SB card not probed since the import of the bridge dirvers, could you please apply the following patch, add the logical ID of your card into sbc_ids[] and see how it works? (I have asked peter to review the PnP part of the patch) Applying your patch made the kernel recognise the soundcard again without adding additional pnp ids. Thanks, Timo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More newpcm breakage
On Tue, Nov 30, 1999 at 10:30:28AM +0900, [EMAIL PROTECTED] wrote: On 29 Nov 1999 19:19:24 +0100, Dag-Erling Smorgrav [EMAIL PROTECTED] said: Dag-Erling My SB32 PnP, which had so far worked nicely with newpcm except for the Dag-Erling "fast forward" bug, stopped working after the newmidi import. This Dag-Erling means that none of my sound cards (except for the GUS PnP, which I Dag-Erling haven't tested) work any more, and I am seriously losing faith in the Dag-Erling authors' ability to maintain a device driver. Did you add sbc into your kernel configuration? Maybe I should add a warning in sb.c... I don't if DES did, but I did. Turns out from his dmesg that he has a very similar hardware config (which is why I don't include a copy of my dmesg) and I am seeing *exactly* the same problems - suddenly my AWE32 is not recognized any more. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernel hangs during boot with pnp sio.
On Mon, Oct 04, 1999 at 11:12:10PM -0400, Matthew N. Dodd wrote: On Mon, 4 Oct 1999, Timo Geusch wrote: If you're interested I can send you the source code for the driver but it is not clear if it works on -current at the moment as I haven't updated for some time. Send it here as I'm working on if_ep in some fashion. I'll send it once I verified that it (still) works with -current. The work dates from before newpnp, Also, some indication as to where you made changes would benice - my PnP changes are pretty self-contained but I made some more general changes that might cause problems. Anyway I'll get back to you end of next week (earliest I can manage). Someone find me a verified PnP 3c509 too. I'll pay shipping and $10 for one. I've got a normal 3c509 and a 3c579 in transit and a 3c529 in use. I'd be interested in a 3c589 for testing purposes but at this point it would be of little use has I've not yet put my hands on a ISA to PCMCIA reader. Afaik all 3C509B's are PnP. At least here in the UK there is not shortage of those cards. Timo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep0 etherlink III breakage
On Wed, Sep 22, 1999 at 10:40:22AM +0800, Peter Wemm wrote: No, it's better to remove "device ep0 at isa ? port foo irq blah ..." etc and just have "device ep0" *only*. If the pnp code finds it, let it use pnp to configure it. Does it do that by now? About two or three months ago it didn't and I started writing the necessary code. Now I'm just learning how to remotely debug the kernel... Cheers, Timo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make aout-to-elf on -current?
I had to try this due to an unfortunate 'accident', and no, it currently does not work. The aout assembler complains about a '.section' tag in the assembly output of contrib/gcc/cp/tinfo2.cc. You have to elfify your system with a non-egcs compiler before you can move onto using egcs to make the world. Timo On Fri, Apr 16, 1999 at 12:54:32AM -0600, Warner Losh wrote: Does make aout-to-elf still purport to work from a 2.2.8R system to a recent (like today's) current? Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
'make buildworld' seems to create wrong symlinks for 'obj'
After recvsupping -current from the uk Mirror this morning, 'make buildworld' completed without any problem, but a subsequent 'make installworld' failed when trying to install shared libraries (in this case, libdescrypt.so.2). Further investigation showed that building the aout part of world seems to clobber the symlinks to the 'obj' directories from the source tree, i.e. instead of linking obj into the default 'elf' part of the tree (usr/obj/usr...) the link was pointing into the aout part of the object tree and therefore all elf libraries could not be installed. After completely nuking everything in /usr/obj the problem persisted, but remaking the world with -DNOAOUT did the trick. Could somebody with more experience regarding 'make world' please look into this? Cheers, Timo To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
