Re: AHC0 fireworks ?
In message <[EMAIL PROTECTED]> "Justin T. Gibbs" writes: : Parity errors indicate that data integrity is compromised on your SCSI : cable. Perhaps you bumped a connector, or a connector had been loose : for a long time and has just shifted to the point of causing a failure. : Open your case, reseat everything and see if the problem clears up. I've also seen parity errors where the drive generated '0' for its parity bit and needed a jumper setting changed. I've had three tape drives and one cd player do this to me over the years. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Fast forward" bug and newpcm (again)
On Tue, 30 Nov 1999, Seigo Tanimura wrote: > On Tue, 30 Nov 1999 01:41:20 -0500, > Donn Miller <[EMAIL PROTECTED]> said: > > Donn> Now, the question is, do I use the Sound Blaster bridge driver > Donn> for the ESS 1868? And, is my ordering wrong? > > sbc driver does not probe ESS1868 at this moment. Question: will the ESS 1868 bridge driver be incorporated into the sbc driver, or should we devise a whole new bridge driver for the ess? I.e., we would have: device ess0 # ESS bridge driver if we write a separate ess bridge driver. I'll look over some of the bridge driver source code to see what needs to be done. Hopefully, I can help out in some way. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More newpcm breakage
-On [19991129 19:49], Dag-Erling Smorgrav ([EMAIL PROTECTED]) wrote: >My SB32 PnP, which had so far worked nicely with newpcm except for the >"fast forward" bug, stopped working after the newmidi import. This >means that none of my sound cards (except for the GUS PnP, which I >haven't tested) work any more, and I am seriously losing faith in the >authors' ability to maintain a device driver. This is CURRENT des, things are expected to not work or even break at times. And instead of just throwing out and voicing this `loss of faith' you could have taken a more active approach and try and help and see what was causing the actual problems with the not-detection of the cards. Cameron and Tanimura-san have done great work and we getting further and further where we want to go with the new sound support. The FreeBSD Project taught me that it is easy to just bitch and moan, but that the real work only comes when you help with it yourself. That's a lesson you must have learned way before I even joined helping on the project. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai> Network/Security SpecialistBSD: Technical excellence at its best Learn e-mail netiquette: http://www.lemis.com/email.html Sometimes the Heart wanders in fantasies, keeping the mind in its power constantly... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Fast forward" bug and newpcm (again)
On Tue, 30 Nov 1999 01:41:20 -0500, Donn Miller <[EMAIL PROTECTED]> said: Donn> Now, the question is, do I use the Sound Blaster bridge driver Donn> for the ESS 1868? And, is my ordering wrong? sbc driver does not probe ESS1868 at this moment. -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
"Fast forward" bug and newpcm (again)
Yes, I DO have the bridge drivers in my kernel config files, and I still get the "fast forward" effect with my ESS 1868. My guess is that it's just a bug with the ESS 1868 driver, I don't know. Maybe my ordering is wrong? I've had the sbc driver for the ESS ever since the bridge drivers came out. And people want to accuse me of not paying attention. Here's an excerpt from my kernel config: device sbc0 device pcm0 See that, I clearly have the bridge driver in my kernel config. Now, the question is, do I use the Sound Blaster bridge driver for the ESS 1868? And, is my ordering wrong? Actually, I've had the "Fast forward" bug with -current since the beginning of Oct. Maybe it's a thing with the ESS 1868, I don't know. But I did in fact have the bridge drivers in my config file, and compiled/installed the kernel with the sbc bridge driver. One person mentioned that the ESS doesn't want to work unless it's in mss mode (instead of SB compatibility mode). - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
In message <[EMAIL PROTECTED]>, Mike Smith writes: >> >> Ahh, Ok. >> >> Bruce (a little hasty in my mind) removed a compat shim we had, >> please change the 'rda' to 'da' again and all should be fine. > >Actually, I did the dirty work because I agreed with Bruce. What I don't >understand is why the system explodes when it can't find /, rather than >giving up cleanly. devsw(NODEV) bombs. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD security auditing project.
(Damn, go away for Thanksgiving and fall behind on -CURRENT, and miss out on large interesting and fast-paced discussions! I am now subscribed to the new -audit, and probably missed some messages. I've Bcc'd this to -current, but CC'd to -audit under the assumption that that is where it belongs) On Wed, 24 Nov 1999 [EMAIL PROTECTED] wrote: > On Wed, 24 Nov 1999, Doug Rabson wrote: > > > We need to put audit tags into the source tree when a file is audited. > > That allows the diffs to be audited later which should be a smaller job > > and then the audit tag slides forward. > > Not to interrupt in the middle of this discussion but you might > want to check with robert watson before you guys get too deep here since > he is working on a FUNDED Posix.1e implementation for FreeBSD. And has > already posted some EARLY MAC code. It might be usefull to work with him > as well. Just a thought. Chris, That would be the "other" audit -- this auditing is source code auditing for bugs in the code. The POSIX.1e auditing would be event logging/etc. Sadly, they have the same name, and I'm not sure which is the more appropriate activity to have the name :-). That said, there have been past projects to audit the FreeBSD source code, but this seems to have the most steam behind it so far, and I hope it goes forwards. It's important to note that source code auditing is not the only thing that makes OpenBSD more secure -- strong crypto, careful thinking through of information leaking, etc, are also very important. There are many bugs in the security design, not just in the implementation, important as the implementation may be. Strings in C seem to be a huge source of security problems, but needless to say even if we had a better string library, there would still be security problems :-) -- poorly thought out suid programs, incorrect use of setuid to create sandboxes (man, uucp, etc, etc), bad permissions, reliance on privacy of environmental variables, poor random number seeding, misunderstandings about euids/uids/reuids/etc in the context of debugging and tracing, weak defense of /dev/kmem, etc, etc, and there are dozens and dozens of such issues. POSIX.1e extensions attempt to address some of these issues by providing least privilege capabilities, finer grained access control, as well as trusted system behavior such as mandatory access control and auditing. This all also requires serious thought. Source auditing is a great step forwards, however, as it clears up the most commonly exploited security holes that make for bad press and lots of bugtraq announcements. :-) Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MAKEDEV & newpcm driver
On Mon, Nov 29, 1999, Donn Miller wrote: > So, is the right command to make the audio device entries > ./MAKEDEV snd0, or does newpcm have a different method to create > the audio device entries? > > Also, I have an ESS 1868, and I'm getting the "fast forward" > effect with the newpcm driver. It's a SB compatible card. If you read -current, you'd see the HEADS UP about the bridge drivers. Please pay more attention. -- |Chris Costello <[EMAIL PROTECTED]> |Programming is an unnatural act. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep driver troubles
On Mon, 29 Nov 1999, Eric Ogren wrote: > Already there (I can attach my entire config file / dmesg output > to anyone who wants to see it, but I didn't want to dump the whole > thing to the list). How about the output of 'pnpinfo'? Apply this patch: ftp://ftp.jurai.net/users/winter/patches/if_ep.patch -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
On Mon, 29 Nov 1999, O'Shaughnessy Evans wrote: > So could it be that some of your rules are breaking things? I think I've > seen the same error message when trying to write a rule for a non-existant > interface name or a group that wasn't created with "... head N". > > -- > O'Shaughnessy Evans I doubt that, since I used the BASIC_2.FW (the less restrictive one) modified to my xl0 connects. Unless the rules in BASIC_2.FW is completely off? Anyhow, I did try a simple pass in on xl0 all as my ipfilter rules file, and well, same error. Davec -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
On Mon, 29 Nov 1999, O'Shaughnessy Evans wrote: > "Mikhail A. Sokolov" <[EMAIL PROTECTED]> wrote: > > No, it can't. He was refering to ipf -V; I managed to reproduce the > > behaviour several days ago, but since I remade the devices it's ok in > > my case, but in his. Again, no other rules/whatever is being used in > > the test, just ipf -V. > > Makes sense. I get the same message, BTW, on my Solaris 7 box when the > ipf kernel module isn't loaded and I run "ipf -V". > > -- > O'Shaughnessy Evans But I'm not using a loadable kernel module. I compiled IPFilter in my kernel from the FreeBSD source tree with: options IPFILTER options IPFILTER_LOG #optionsIPFILTER_LKM And bootup did show: Nov 28 20:02:34 /kernel: IP Filter: initialized. Default = pass all, Logging = enabled Nov 28 20:02:34 /kernel: IP Filter: v3.3.3 Unfortunately I've only been using FreeBSD for about a year and a half now (excellent platform for program development btw) so I still do not know all the internal workings. But how would I know, aside from /var/log/messages, that IPFilter is loaded and running when not existing as a lkm? -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sbc and pcm
The following patch makes sbc_probe() to look at the vendor ID only
for AWE64. Also, any device that has a logical ID matching 0x??0080ce
should get probed.
Index: sbc.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sbc.c,v
retrieving revision 1.2
diff -u -r1.2 sbc.c
--- sbc.c 1999/11/27 06:33:27 1.2
+++ sbc.c 1999/11/30 02:46:00
@@ -86,86 +86,32 @@
static int
sbc_probe(device_t dev)
{
- u_int32_t vend_id, logical_id, vend_id2;
+ u_int32_t vend_id, logical_id;
char *s;
struct sndcard_func *func;
vend_id = isa_get_vendorid(dev);
- vend_id2 = vend_id & 0xff00;
logical_id = isa_get_logicalid(dev);
s = NULL;
- switch (logical_id) {
-#if notdef
- case 0x630e: /* Crystal Semiconductor */
- if (vend_id2 ==0x3600630e) /* CS4236 */
- s = "CS4236";
- else if (vend_id2 ==0x3200630e) /* CS4232 */
- s = "CS4232";
- else if (vend_id2 ==0x3500630e) /* CS4236B */
- s = "CS4236B";
- break;
-#endif /* notdef */
- case 0x01008c0e: /* Creative ViBRA16C */
- if (vend_id2 == 0x70008c0e)
- s = "Creative ViBRA16C PnP";
- break;
- case 0x43008c0e: /* Creative ViBRA16X */
- if (vend_id2 == 0xf0008c0e)
- s = "Creative ViBRA16C PnP";
- break;
- case 0x31008c0e: /* Creative SB */
- if (vend_id2 == 0x26008c0e)
- s = "Creative SB16 PnP";
- else if (vend_id2 == 0x42008c0e)
- s = "Creative SB32 (CTL0042)";
- else if (vend_id2 == 0x44008c0e)
- s = "Creative SB32 (CTL0044)";
- else if (vend_id2 == 0x48008c0e)
- s = "Creative SB32 (CTL0048)";
- else if (vend_id2 == 0x49008c0e)
- s = "Creative SB32 (CTL0049)";
- else if (vend_id2 == 0xf1008c0e)
- s = "Creative SB32 (CTL00f1)";
- break;
- case 0x42008c0e: /* Creative SB AWE64 (CTL00c1) */
- if (vend_id2 == 0xc1008c0e)
- s = "Creative SB AWE64 (CTL00c1)";
- break;
- case 0x45008c0e: /* Creative SB AWE64 (CTL0045) */
- if (vend_id2 == 0xe4008c0e)
- s = "Creative SB AWE64 (CTL0045)";
- break;
-#if notdef
- case 0x0121: /* Avance Logic */
- if (vend_id2 == 0x20009305)
- s = "Avance Logic ALS120";
- break;
- case 0x0111: /* Avance Asound */
- if (vend_id2 == 0x10009305)
- s = "Avance Asound 110";
- break;
- case 0x68187316: /* ESS1868 */
- if (vend_id2 == 0x68007316)
- s = "ESS ES1868 Plug and Play AudioDrive";
- break;
- case 0x79187316: /* ESS1879 */
- if (vend_id2 == 0x79007316)
- s = "ESS ES1879 Plug and Play AudioDrive";
- break;
- case 0x2100a865: /* Yamaha */
- if (vend_id2 == 0x2000a865)
- s = "Yamaha OPL3-SA2/SAX Sound Board";
- break;
- case 0x80719304: /* Terratec */
- if (vend_id2 == 0x1114b250)
- s = "Terratec Soundsystem Base 1";
- break;
- case 0x0300561e: /* Gravis */
- if (vend_id2 == 0x0100561e)
- s = "Gravis UltraSound Plug & Play";
- break;
-#endif /* notdef */
+ if ((logical_id & 0x00ff) == 0x8c0e) {
+ /* Creative */
+ s = "Creative SB PnP";
+ if ((vendor_id & 0x80ff) == 0x80008c0e) /* SB AWE64 */
+ s = "Creative SB AWE64 PnP";
+ else {
+ switch (logical_id) {
+ case 0x01008c0e: /* ViBRA16C */
+ s = "Creative ViBRA16C PnP";
+ break;
+ case 0x43008c0e: /* ViBRA16X */
+ s = "Creative ViBRA16X PnP";
+ break;
+ case 0x31008c0e: /* SB16/AWE32 */
+ s = "Creative SB16/AWE32 PnP";
+ break;
+ }
+ }
}
if (s != NULL) {
Re: sbc and pcm
On Tue, 23 Nov 1999 04:22:39 +0800, Peter Wemm <[EMAIL PROTECTED]> said: >> Mostly, sbc.c is handling PnP ID matching in a totally bogus manner. Peter> Yes, it's quite bogus and is incompatible with motherboard devices. There Peter> should be no vendor ID references in there at all, that's for card ID, not Peter> device id. I am now working to tidy up the sbc probe. Would it be enough for the sound chips on motherboards to check the logical device ID of 0x??008c0e? How does the result of pnpinfo(1) for a motherboard chip look like? -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sbc and pcm
[EMAIL PROTECTED] wrote:
> On Tue, 23 Nov 1999 04:22:39 +0800,
> Peter Wemm <[EMAIL PROTECTED]> said:
>
> >> Mostly, sbc.c is handling PnP ID matching in a totally bogus manner.
>
> Peter> Yes, it's quite bogus and is incompatible with motherboard devices. T
here
> Peter> should be no vendor ID references in there at all, that's for card ID,
not
> Peter> device id.
>
> I am now working to tidy up the sbc probe. Would it be enough for the
> sound chips on motherboards to check the logical device ID of 0x??008c0e?
No.. At the very least, do something like the attached patch. Preferably
go further and use 'struct isa_pnp_id sbc_ids[]' and
error = ISA_PNP_PROBE(device_get_parent(dev), dev, sbc_ids);
if (error == ENXIO)
return ENXIO;
...
Also, don't add the children until attach time. There is no guarantee that
just because your probe succeeded that you'll actually be attached, something
else might out-bid you for the device id.
> How does the result of pnpinfo(1) for a motherboard chip look like?
There is no pnpinfo for it. It has a logical device ID only with no vendor ID.
Minimal patch appended..
Cheers,
-Peter
Index: sbc.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sbc.c,v
retrieving revision 1.2
diff -c -r1.2 sbc.c
*** sbc.c 1999/11/27 06:33:27 1.2
--- sbc.c 1999/11/30 03:26:47
***
*** 82,206
static devclass_t sbc_devclass;
- #if NISA > 0 && NPNP > 0
- static int
- sbc_probe(device_t dev)
- {
- u_int32_t vend_id, logical_id, vend_id2;
- char *s;
- struct sndcard_func *func;
! vend_id = isa_get_vendorid(dev);
! vend_id2 = vend_id & 0xff00;
! logical_id = isa_get_logicalid(dev);
! s = NULL;
! switch (logical_id) {
#if notdef
! case 0x630e: /* Crystal Semiconductor */
! if (vend_id2 ==0x3600630e) /* CS4236 */
! s = "CS4236";
! else if (vend_id2 ==0x3200630e) /* CS4232 */
! s = "CS4232";
! else if (vend_id2 ==0x3500630e) /* CS4236B */
! s = "CS4236B";
! break;
! #endif /* notdef */
! case 0x01008c0e: /* Creative ViBRA16C */
! if (vend_id2 == 0x70008c0e)
! s = "Creative ViBRA16C PnP";
! break;
! case 0x43008c0e: /* Creative ViBRA16X */
! if (vend_id2 == 0xf0008c0e)
! s = "Creative ViBRA16C PnP";
! break;
! case 0x31008c0e: /* Creative SB */
! if (vend_id2 == 0x26008c0e)
! s = "Creative SB16 PnP";
! else if (vend_id2 == 0x42008c0e)
! s = "Creative SB32 (CTL0042)";
! else if (vend_id2 == 0x44008c0e)
! s = "Creative SB32 (CTL0044)";
! else if (vend_id2 == 0x48008c0e)
! s = "Creative SB32 (CTL0048)";
! else if (vend_id2 == 0x49008c0e)
! s = "Creative SB32 (CTL0049)";
! else if (vend_id2 == 0xf1008c0e)
! s = "Creative SB32 (CTL00f1)";
! break;
! case 0x42008c0e: /* Creative SB AWE64 (CTL00c1) */
! if (vend_id2 == 0xc1008c0e)
! s = "Creative SB AWE64 (CTL00c1)";
! break;
! case 0x45008c0e: /* Creative SB AWE64 (CTL0045) */
! if (vend_id2 == 0xe4008c0e)
! s = "Creative SB AWE64 (CTL0045)";
! break;
#if notdef
! case 0x0121: /* Avance Logic */
! if (vend_id2 == 0x20009305)
! s = "Avance Logic ALS120";
! break;
! case 0x0111: /* Avance Asound */
! if (vend_id2 == 0x10009305)
! s = "Avance Asound 110";
! break;
! case 0x68187316: /* ESS1868 */
! if (vend_id2 == 0x68007316)
! s = "ESS ES1868 Plug and Play AudioDrive";
! break;
! case 0x79187316: /* ESS1879 */
! if (vend_id2 == 0x79007316)
! s = "ESS ES1879 Plug and Play AudioDrive";
! break;
! case 0x2100a865: /* Yamaha */
! if (vend_id2 == 0x2000a865)
! s = "Yamaha OPL3-SA2/SAX Sound Board";
! break;
! case 0x80719304: /* Terratec */
! if (vend_id2 == 0x1114b250)
! s = "Terratec Soundsystem Base 1";
! break;
! case 0x0300561e: /* Gravis */
! if (vend_id2 == 0x0100561e)
! s = "Gravis UltraSound Plug & Play";
! break;
! #endif /* notdef */
! }
!
! if (s != NULL) {
! device_set_desc(dev, s);
!
! /* PCM Audio */
! f
Re: IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
"Mikhail A. Sokolov" <[EMAIL PROTECTED]> wrote: > On Mon, Nov 29, 1999 at 02:15:16PM -0800, O'Shaughnessy Evans wrote: > # Davec <[EMAIL PROTECTED]> wrote: > # [...] > # > But when I try to load any rules, I get the error messages above. > # > Same result with ipnat. I checked to make sure I was using the > # > right version of ipf: > # [...] > # > # So could it be that some of your rules are breaking things? I think I've > # seen the same error message when trying to write a rule for a non-existant > # interface name or a group that wasn't created with "... head N". > > No, it can't. He was refering to ipf -V; I managed to reproduce the > behaviour several days ago, but since I remade the devices it's ok in > my case, but in his. Again, no other rules/whatever is being used in > the test, just ipf -V. Makes sense. I get the same message, BTW, on my Solaris 7 box when the ipf kernel module isn't loaded and I run "ipf -V". -- O'Shaughnessy Evans To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ep driver troubles
On Mon, 29 Nov 1999, Matthew N. Dodd wrote: > On Sun, 28 Nov 1999, Eric Ogren wrote: > > I just recently upgraded to 4.0-CURRENT, and I can't seem to get the > > new ep driver to recognize my 3c509b card (yes, I know it's an awful > > NIC, but it's what I have, and it's worked fine for me). > > put > > controller pnp0 > > in your config file. Already there (I can attach my entire config file / dmesg output to anyone who wants to see it, but I didn't want to dump the whole thing to the list). Eric To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crash under high exec() loads.. (vm_map_insert?)
:the timeout to kill it off because of the interactive mode. Otherwise :there was ~960,000 accumulated exec()'s altogether in a 5 hour period. : :As you can see, cron is the process that crashed it. Two weeks ago it :was an eggdrop. I've not had any crashes in -CURRENT while this program :was not running however. : :If you notice, both times it crashed on vm_map_insert. Try bumping up PMAP_SHPGPERPROC. From LINT: # # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". # # The value below is the one more than the default. # options PMAP_SHPGPERPROC=201 Try bumping it up to 1000 and see if that solves your crashes. If that doesn't work, and there's any chance of getting a kernel dump, try getting a kernel dump. Make sure you use a debug (compiled -g) kernel. -Matt Matthew Dillon <[EMAIL PROTECTED]> :Fatal trap 12: page fault while in kernel mode :fault virtual address = 0x8 :fault code = supervisor write, page not present :instruction pointer = 0x8:0xc01d7a67 :stack pointer = 0x10:0xccd67df0 :frame pointer = 0x10:0xccd67e0c :code segment= base 0x0, limit 0xf, type 0x1b := DPL 0, pres 1, def32 1, gran 1 :processor eflags= interrupt enabled, resume, IOPL = 0 :current process = 128 (cron) :interrupt mask = none :trap number = 12 :panic: page fault : :syncing disks... 32 9 :done : :dumping to dev #wd/0x20001, offset 1413889 :dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 :74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 :50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 :26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 :--- :#0 0xc0131e80 in boot () :#1 0xc013221d in panic () :#2 0xc0215102 in trap_fatal () :#3 0xc0214db5 in trap_pfault () :#4 0xc0214987 in trap () :#5 0xc01d7a67 in vm_map_insert () <=== :#6 0xc01d7c88 in vm_map_find () :#7 0xc01d6e93 in kmem_alloc_pageable () :#8 0xc0211a3e in pmap_pinit () :#9 0xc01d7650 in vmspace_alloc () :#10 0xc01d950c in vmspace_fork () :#11 0xc01d6a28 in vm_fork () :#12 0xc012c96f in fork1 () :#13 0xc012c1f6 in fork () :#14 0xc021533a in syscall () :#15 0xc0209d36 in Xint0x80_syscall () :#16 0x804aeee in ?? () :#17 0x8049c4d in ?? () :#18 0x8049a15 in ?? () :#19 0x80497d9 in ?? () : :thomas r. stromberg smtp:[EMAIL PROTECTED] :assistant is manager / systems guru http://thomas.stromberg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More newpcm breakage
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... -- Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
On Mon, Nov 29, 1999 at 02:15:16PM -0800, O'Shaughnessy Evans wrote: # Davec <[EMAIL PROTECTED]> wrote: # [...] #> But when I try to load any rules, I get the error messages above. Same result # > with ipnat. I checked to make sure I was using the right version of ipf: # [...] # # So could it be that some of your rules are breaking things? I think I've # seen the same error message when trying to write a rule for a non-existant # interface name or a group that wasn't created with "... head N". No, it can't. He was refering to ipf -V; I managed to reproduce the behaviour several days ago, but since I remade the devices it's ok in my case, but in his. Again, no other rules/whatever is being used in the test, just ipf -V. # -- # O'Shaughnessy Evans -- -mishania To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
:> Bruce (a little hasty in my mind) removed a compat shim we had, :> please change the 'rda' to 'da' again and all should be fine. : :Actually, I did the dirty work because I agreed with Bruce. What I don't :understand is why the system explodes when it can't find /, rather than :giving up cleanly. : :If Matt's change makes these 'r' devices work again, it's broken and :needs to be backed out (I'm still updating, will look soon). Negative. I just fixed a NULL pointer dereference bug. I haven't touched the 'r' devices. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
> > Ahh, Ok. > > Bruce (a little hasty in my mind) removed a compat shim we had, > please change the 'rda' to 'da' again and all should be fine. Actually, I did the dirty work because I agreed with Bruce. What I don't understand is why the system explodes when it can't find /, rather than giving up cleanly. If Matt's change makes these 'r' devices work again, it's broken and needs to be backed out (I'm still updating, will look soon). > Poul-Henning > > In message <[EMAIL PROTECTED]>, Manfred Antar writes: > >At 09:55 PM 11/29/99 +0100, Poul-Henning Kamp wrote: > > > >>Do you have /dev/sd* in your /etc/fstab ? > >> > >>It should be changed to /dev/da* > >This is what I have > > > ># DeviceMountpoint FStype Options DumpPass# > >/dev/rda0s1bnoneswapsw 0 0 > >/dev/rda0s1a/ ufs rw 1 1 > >/dev/rda0s1e /var ufsrw 2 2 > >/dev/rda0s1f/usrufs rw 2 2 > >/dev/rda0s1g /usr/obj ufsrw2 2 > >proc/proc procfs rw0 0 > >/dev/cd0a /cdrom cd9660 ro,noauto 0 0 > > > > > >Should I change cd0a to rcd0a ? > >Any way it boots now with version 1.46 of vfs_conf.c that Mike just committed > >Thanks > >Manfred > >= > >||[EMAIL PROTECTED] || > >||Ph. (415) 681-6235|| > >= > > > > > > -- > Poul-Henning Kamp FreeBSD coreteam member > [EMAIL PROTECTED] "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
:I compiled a kernel with it, and no panic!! Here's what I get instead: : :[vshah@jabberwock] ~> rm index.html :rm: index.html: No such file or directory :2220 [6:41pm] :[vshah@jabberwock] ~> ln -s public_html/index.html ./index.html :ln: ./index.html: RPC struct is bad :2221 [6:41pm] :[vshah@jabberwock] ~> ls -la index.html :lrwxr-xr-x 1 vshah staff 22 Nov 29 18:41 index.html@ -> public_html/index.html : : :Does that do what it is suppossed to? Why the "RPC struct is bad"? Ho ho. Well, at least we fixed the panic! Gotta go! (Matt runs away). Just kidding. Lets take this out of -current, please. I'll send you another email which you can respond to. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
Matt> I've added a little cleanup to this patch. Viren, please try this
Matt> patch.
I compiled a kernel with it, and no panic!! Here's what I get instead:
[vshah@jabberwock] ~> rm index.html
rm: index.html: No such file or directory
2220 [6:41pm]
[vshah@jabberwock] ~> ln -s public_html/index.html ./index.html
ln: ./index.html: RPC struct is bad
2221 [6:41pm]
[vshah@jabberwock] ~> ls -la index.html
lrwxr-xr-x 1 vshah staff 22 Nov 29 18:41 index.html@ -> public_html/index.html
Does that do what it is suppossed to? Why the "RPC struct is bad"?
Matt> -Matt
Matt> Index: nfs_vnops.c
Matt> ===
Matt> RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfs_vnops.c,v
Matt> retrieving revision 1.146
Matt> diff -u -r1.146 nfs_vnops.c
Matt> --- nfs_vnops.c 1999/11/27 18:14:41 1.146
Matt> +++ nfs_vnops.c 1999/11/29 23:23:05
Matt> @@ -1806,11 +1806,10 @@
Matt> txdr_nfsv2time(&vap->va_mtime, &sp->sa_mtime);
Matt> }
Matt> nfsm_request(dvp, NFSPROC_SYMLINK, cnp->cn_proc, cnp->cn_cred);
Matt> -if (v3) {
Matt> -if (!error)
Matt> -nfsm_mtofh(dvp, newvp, v3, gotvp);
Matt> +if (!error)
Matt> +nfsm_mtofh(dvp, newvp, v3, gotvp);
Matt> +if (v3)
Matt> nfsm_wcc_data(dvp, wccflag);
Matt> -}
Matt> nfsm_reqdone;
Matt> /*
Matt> * Kludge: Map EEXIST => 0 assuming that it is a reply to a retry.
Matt> @@ -1821,8 +1820,9 @@
Matt> if (error) {
Matt> if (newvp)
Matt> vput(newvp);
Matt> -} else
Matt> +} else {
Matt> *ap->a_vpp = newvp;
Matt> +}
Matt> VTONFS(dvp)->n_flag |= NMODIFIED;
Matt> if (!wccflag)
Matt> VTONFS(dvp)->n_attrstamp = 0;
Viren
--
Viren Shah| "You can't trust code that you did not totally
Research Associate, RST Inc. | create yourself. (Especially code from
[EMAIL PROTECTED] | companies that employ people like me.)"
http://www.rstcorp.com/~vshah | - Ken Thompson "Reflections on Trusting Trust"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: State of Alpha support and Oracle.
> > http://www.relex.ru/linter/ > > This looks pretty neat. Has anybody actually used this under FreeBSD? > Any comments? One of the tricky things about selecting FreeBSD software > is how commited the vendor is towards the OS. I'd hate to commit to > something like this and then have the vendor stop supporting FreeBSD in > the future. I've seen it running, and we're doing what we can to evaluate it in-house with the FreeBSD Mall folks, but I can't comment on how it performs in production. As for commitment; Relex are a fairly large organisation (about 100 developers), and they have a sales/support branch in the USA, so I'm fairly comfortable with their level of commitment. It's hard to give any sort of certain answer, of course. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
> "Matt" == Matthew Dillon <[EMAIL PROTECTED]> writes:
Matt> I've added a little cleanup to this patch. Viren, please try this
Matt> patch.
Matt> -Matt
Matt> Matthew Dillon
Matt> <[EMAIL PROTECTED]>
Matt> Index: nfs_vnops.c
Matt> ===
Matt> RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfs_vnops.c,v
Matt> retrieving revision 1.146
Matt> diff -u -r1.146 nfs_vnops.c
Matt> --- nfs_vnops.c 1999/11/27 18:14:41 1.146
Matt> +++ nfs_vnops.c 1999/11/29 23:23:05
Matt> @@ -1806,11 +1806,10 @@
Matt> txdr_nfsv2time(&vap->va_mtime, &sp->sa_mtime);
Matt> }
Matt> nfsm_request(dvp, NFSPROC_SYMLINK, cnp->cn_proc, cnp->cn_cred);
Matt> -if (v3) {
Matt> -if (!error)
Matt> -nfsm_mtofh(dvp, newvp, v3, gotvp);
Matt> +if (!error)
Matt> +nfsm_mtofh(dvp, newvp, v3, gotvp);
^^
Should that still be "v3"? Since you moved it out of the "if (v3)"
block, sholudn't it say something else?
Viren
--
Viren Shah| "You can't trust code that you did not totally
Research Associate, RST Inc. | create yourself. (Especially code from
[EMAIL PROTECTED] | companies that employ people like me.)"
http://www.rstcorp.com/~vshah | - Ken Thompson "Reflections on Trusting Trust"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
:I think I (well, Alfred Perlstein) have found what the problem is - in
:nfs_symlink, newvp isn't initialized for NFSv2. Unfortunately, I have
:zero clue about how to fix that - Alfred believes the checks for NFSv3
:may not be necessary - myself, I find the NFS code almost totally
:incomprehensible, and have tried to keep my fingers as much out of it
:as possible, but for the changes I'm working on now I have to touch it
::-(
:
:Eivind.
Yes, I concur. There are also problems with the ASSERT_VOP_*() macros...
the filesystem code is not very good at NULLing out dead fields in namei()
requests (it has caused me no end of trouble), so you can't assume
that a non-null pointer is valid in the ASSERT's. You *must* check the
error return.
But that is not what caused the bug. Alfred has it tagged.
if (v3) {
if (!error)
nfsm_mtofh(dvp, newvp, v3, gotvp);
nfsm_wcc_data(dvp, wccflag);
}
nfsm_wcc_data() is an NFSv3 only mechanism, I believe. But the
if (!error) nfsm_mtofh(...) can be moved to outside (before) that
conditional. I'll patch it in and test it. Also, the nfsm macros
are dangerous.
I've added a little cleanup to this patch. Viren, please try this
patch.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
Index: nfs_vnops.c
===
RCS file: /FreeBSD/FreeBSD-CVS/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.146
diff -u -r1.146 nfs_vnops.c
--- nfs_vnops.c 1999/11/27 18:14:41 1.146
+++ nfs_vnops.c 1999/11/29 23:23:05
@@ -1806,11 +1806,10 @@
txdr_nfsv2time(&vap->va_mtime, &sp->sa_mtime);
}
nfsm_request(dvp, NFSPROC_SYMLINK, cnp->cn_proc, cnp->cn_cred);
- if (v3) {
- if (!error)
- nfsm_mtofh(dvp, newvp, v3, gotvp);
+ if (!error)
+ nfsm_mtofh(dvp, newvp, v3, gotvp);
+ if (v3)
nfsm_wcc_data(dvp, wccflag);
- }
nfsm_reqdone;
/*
* Kludge: Map EEXIST => 0 assuming that it is a reply to a retry.
@@ -1821,8 +1820,9 @@
if (error) {
if (newvp)
vput(newvp);
- } else
+ } else {
*ap->a_vpp = newvp;
+ }
VTONFS(dvp)->n_flag |= NMODIFIED;
if (!wccflag)
VTONFS(dvp)->n_attrstamp = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
-CURRENT crash under high exec() loads.. (vm_map_insert?)
While doing some testing (and actually, in the middle of me trying to post some results) for the FreeBSD Auditing project, my 4.0-CURRENT box crashed. These tests involved a barrage of automated exec() calls which I suspect is what tore it down. I had a similar crash two weeks ago, but did not have the kernel set for debug mode, so I wrote just a quick summary on the bottom of the trace. This may of course have absolutely nothing to do with the testing, as it was (at time of crash) testing /usr/bin/bc, which is mostly waiting on the timeout to kill it off because of the interactive mode. Otherwise there was ~960,000 accumulated exec()'s altogether in a 5 hour period. As you can see, cron is the process that crashed it. Two weeks ago it was an eggdrop. I've not had any crashes in -CURRENT while this program was not running however. If you notice, both times it crashed on vm_map_insert. Enviroment: --- Machine: PIII-500, 96M RAM uname: FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue Nov 23 07:31:52 EST 1999 root@:/usr/src/sys/compile/KARMA i386 load: ~1.20 Conditions: --- X w/ Netscape 4.7 was running 'breakwidgets' was pumping out up to 5000 exec() calls a minute. (depending on timeouts). At time of crash it was probably more like 30-100 execs a minute. (I suspect the latter, naturally). Dump: - IdlePTD 3022848 initial pcb at 26d3e0 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d7a67 stack pointer = 0x10:0xccd67df0 frame pointer = 0x10:0xccd67e0c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 128 (cron) interrupt mask = none trap number = 12 panic: page fault syncing disks... 32 9 done dumping to dev #wd/0x20001, offset 1413889 dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc0131e80 in boot () #1 0xc013221d in panic () #2 0xc0215102 in trap_fatal () #3 0xc0214db5 in trap_pfault () #4 0xc0214987 in trap () #5 0xc01d7a67 in vm_map_insert () <=== #6 0xc01d7c88 in vm_map_find () #7 0xc01d6e93 in kmem_alloc_pageable () #8 0xc0211a3e in pmap_pinit () #9 0xc01d7650 in vmspace_alloc () #10 0xc01d950c in vmspace_fork () #11 0xc01d6a28 in vm_fork () #12 0xc012c96f in fork1 () #13 0xc012c1f6 in fork () #14 0xc021533a in syscall () #15 0xc0209d36 in Xint0x80_syscall () #16 0x804aeee in ?? () #17 0x8049c4d in ?? () #18 0x8049a15 in ?? () #19 0x80497d9 in ?? () Two weeks beforehand this was the crash trace (I wrote it down, if need be, I can re-type all the nasty details) vm_map_insert c0272568, 0, 0, 0, cf294000 @ 0x18c <=== vm_map_find kmem_alloc_pageable pmap_pinit vmspace_alloc vmspace_exec exec_new_vmspace eec_elf_imgact execve syscall xint0x80_syscall -- == thomas r. stromberg smtp:[EMAIL PROTECTED] assistant is manager / systems guru http://thomas.stromberg.org research triangle commerce, inc.finger:[EMAIL PROTECTED] 'om mani pedme hung'pots://1.919.380.9771:3210 [eof]= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
:> Eivind, I'm not sure that change you made is legal. People use :> symlink creation the same way they use O_EXCL file creation - as a :> locking mechanism. In fact, in NFSv2 O_EXCL file creation is not :> atomic (I'm pretty sure) and symlink was the *only* method available. : :The sum of the changes I made does not (or is at least not supposed :to) change the semantics of symlink creation. If you see some way the :semantics are changed, please tell me - that's an error. Ah, ok. Now I see what you've done. I'm still not sure that's right, I'll have to go over it in more detail. I'll get back to you in private email. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
:OK, here's a -current system from today (11/29) morning [4am EST] with :kernel compiled with DDB and -g. : :Tried doing a simple symlink over a NFS mounted filesystem: : :fatal trap 12: page fault while in kernel mode :fault virtual address = 0x4 :fault code= supervisor read, page not present :instruction pointer = 0x8:0xc0167979 :... :db> trace : : vput(0) at vput+0x11 : symlink (c9d4e200, c9d74f80, bfbfdab5, bfbfda9e, bfbfd99c) at symlink+0x1e3 : syscall(2f, 2f, 2f, bfbfd99c, bfbfda9e) at syscall+0x176 : Xint0x80_syscall() at Xint0x80_syscall+0x26 I believe the problem is with the ASSERT_VOP_UNLOCKED macros that have been added to the symlink code in kern/vfs_syscalls.c, near the end of the procedure. Also, I think there's a race condition with the ASSERT_VOP_UNLOCKED() macros... when a vnode is vput it is possible for it to be freed up, the assert may not be valid at that point. Please try this patch: -Matt Index: vfs_syscalls.c === RCS file: /FreeBSD/FreeBSD-CVS/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.146 diff -u -r1.146 vfs_syscalls.c --- vfs_syscalls.c 1999/11/20 10:00:40 1.146 +++ vfs_syscalls.c 1999/11/29 23:01:09 @@ -1307,7 +1307,8 @@ vput(nd.ni_vp); vput(nd.ni_dvp); ASSERT_VOP_UNLOCKED(nd.ni_dvp, "symlink"); - ASSERT_VOP_UNLOCKED(nd.ni_vp, "symlink"); + if (error == 0) + ASSERT_VOP_UNLOCKED(nd.ni_vp, "symlink"); out: zfree(namei_zone, path); return (error); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
On Mon, Nov 29, 1999 at 11:56:31PM +0100, Eivind Eklund wrote: > I've been peering over the code, and I am unable to find anything > wrong :-( I've also gotten panic information and symbol information > from Viren, but this hasn't made me any wiser - the failure was in > setlock (which seems to be an assembler symbol related to > simplelock()), but this isn't of much help. Actually, this info was from Lester Igo, not Viren. Sorry for the misattributation. Eivind. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
On Mon, Nov 29, 1999 at 01:52:29PM -0800, Matthew Dillon wrote:
> :
> : Eivind> I *think* I know what this is due to - please upgrade
> : Eivind> src/sys/nfs/nfs_vnops.c to revision 1.146 (which I just
> : Eivind> committed) and try again.
> :
> :Tried it. Doesn't work. :-( It still crashes when creating a symbolic
> :link on a NFS mounted filesystem. [This is unfortunate in my case,
> :as it prevents me from running Netscape -- the home dirs are NFS
> :mounted]
>
> Eivind, I'm not sure that change you made is legal. People use
> symlink creation the same way they use O_EXCL file creation - as a
> locking mechanism. In fact, in NFSv2 O_EXCL file creation is not
> atomic (I'm pretty sure) and symlink was the *only* method available.
The sum of the changes I made does not (or is at least not supposed
to) change the semantics of symlink creation. If you see some way the
semantics are changed, please tell me - that's an error.
> If you blow away the error you will probably break a good deal of
> third party code.
I haven't added anything to blow away the error - I've moved code that
already was there up before code I added that depended on the error
being the same as what was returned.
I've been peering over the code, and I am unable to find anything
wrong :-( I've also gotten panic information and symbol information
from Viren, but this hasn't made me any wiser - the failure was in
setlock (which seems to be an assembler symbol related to
simplelock()), but this isn't of much help.
The only idea I have for a flaw right now is that if newvp in
nfs_symlink can somehow be NULL in the non-error case, then my code is
in error. The following patch adds a test for this:
Index: nfs/nfs_vnops.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_vnops.c,v
retrieving revision 1.146
diff -u -r1.146 nfs_vnops.c
--- nfs_vnops.c 1999/11/27 18:14:41 1.146
+++ nfs_vnops.c 1999/11/29 22:51:12
@@ -1821,8 +1821,10 @@
if (error) {
if (newvp)
vput(newvp);
- } else
+ } else {
+ KASSERT(newvp, ("No vp in nfs_symlink"));
*ap->a_vpp = newvp;
+ }
VTONFS(dvp)->n_flag |= NMODIFIED;
if (!wccflag)
VTONFS(dvp)->n_attrstamp = 0;
If somebody can run this and tell me if they get this panic instead of
the old one, I'd appreciate it.
Eivind, who thinks this might indicate he will have to set up an NFS
testing environment :-/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
> "Matt" == Matthew Dillon <[EMAIL PROTECTED]> writes: Matt> The problem is a NULL pointer dereference somewhere... please Matt> nm your kernel binary and extract out all elements with c0163 Matt> in them. e.g. nm /kernel | fgrep c0163 | sort. OK, here's a -current system from today (11/29) morning [4am EST] with kernel compiled with DDB and -g. FreeBSD jabberwock 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Nov 29 17:11:27 EST 1999 vshah@jabberwock:/home/ncvs/FreeBSD/current-src/src/sys/compile/J39 i386 Tried doing a simple symlink over a NFS mounted filesystem: fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code= supervisor read, page not present instruction pointer = 0x8:0xc0167979 stack pointer = 0x10:0xc9d74e40 frame pointer = 0x10:0xc9d74e58 code segment = base 0x0; limit 0xf, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor flags = interrupt enabled, resume, 10PL = 0 current process = 315 (ln) interrupt mask= none kernel: type 12 trap code = 0 db> trace vput(0) at vput+0x11 symlink (c9d4e200, c9d74f80, bfbfdab5, bfbfda9e, bfbfd99c) at symlink+0x1e3 syscall(2f, 2f, 2f, bfbfd99c, bfbfda9e) at syscall+0x176 Xint0x80_syscall() at Xint0x80_syscall+0x26 db> show reg ... eip 0xc0167979 vput+0x11 efl 0x10286nfs_write+0xe2 Hope this helps. If there is anything else I can do to debug this, let me know. Viren -- Viren Shah| "You can't trust code that you did not totally Research Associate, RST Inc. | create yourself. (Especially code from [EMAIL PROTECTED] | companies that employ people like me.)" http://www.rstcorp.com/~vshah | - Ken Thompson "Reflections on Trusting Trust" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
: :> :> makeoptions DEBUG="-g" :> :Easier option.. :config -g Actually no. How many people remember to type options after 'config' ? Especially if you are juggling more then one kernel config, trying to remember which ones you intend to compile -g and which ones you don't generally results in forgetting to type -g half the time even on the ones you want it on. If it is in the kernel config, you don't have to remember anything, you simply 'config FILENAME' and you are done. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
> > makeoptions DEBUG="-g" > Easier option.. config -g To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
Davec <[EMAIL PROTECTED]> wrote: [...] > But when I try to load any rules, I get the error messages above. Same result > with ipnat. I checked to make sure I was using the right version of ipf: [...] So could it be that some of your rules are breaking things? I think I've seen the same error message when trying to write a rule for a non-existant interface name or a group that wasn't created with "... head N". -- O'Shaughnessy Evans "Enter any 11-digit prime number to continue." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
:not having DDB compiled into the kernel I can't answer that. However :I'm willing to give any suggestions a go. : : >> [BTW: the server hasn't crashed, it's only the FreeBSD client that : >> crashes] : : Greg> Do you mean the client process or the client operating system? : :The client OS -- immediately after creating the symlink. : :This is the panic I got (taken before Eivind's nfs_vnops.c commit :(rev 1.146) : : :fatal trap 12: page fault while in kernel mode :fault virtual address = 0x4 :fault code= supervisor read, page not present :instruction pointer = 0x8:0xc0163a05 :stack pointer = 0x10:0xc9d77e40 The problem is a NULL pointer dereference somewhere... please nm your kernel binary and extract out all elements with c0163 in them. e.g. nm /kernel | fgrep c0163 | sort. DDB is the better way to do it, because you can 'trace', but nm works in a crunch. And for gods sakes everyone, at least compile your kernels -g In your kernel config (/usr/src/sys/i386/conf/YOURKERNEL), add this: makeoptions DEBUG="-g" -Matt Matthew Dillon <[EMAIL PROTECTED]> : :Viren :-- :Viren Shah| "You can't trust code that you did not totally To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
: : Eivind> I *think* I know what this is due to - please upgrade : Eivind> src/sys/nfs/nfs_vnops.c to revision 1.146 (which I just : Eivind> committed) and try again. : :Tried it. Doesn't work. :-( It still crashes when creating a symbolic :link on a NFS mounted filesystem. [This is unfortunate in my case, :as it prevents me from running Netscape -- the home dirs are NFS :mounted] Eivind, I'm not sure that change you made is legal. People use symlink creation the same way they use O_EXCL file creation - as a locking mechanism. In fact, in NFSv2 O_EXCL file creation is not atomic (I'm pretty sure) and symlink was the *only* method available. It goes like this: * create the symlink * If it succeeds, you are done, you own the lock. * If it does not succeed, read the symlink to determine if the lock is valid. If the lock is not valid you have to wait for a mechanism running on the server to clear it, If the lock is valid and it is yours (you determine this from the contents) then you already own the lock and can continue. If the lock is valid and not yours, you sleep and loop. If you blow away the error you will probably break a good deal of third party code. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
> "Greg" == Greg Lehey <[EMAIL PROTECTED]> writes: Greg> On Saturday, 27 November 1999 at 10:26:15 -0500, Viren R.Shah wrote: >> >> I'm running a -current system from Nov 26th (approx 4am EST). >> >> I can currently reliably crash the system by doing: >> >> ln -s /home/users/vshah/public_html/index.html /home/users/vshah/index.html >> >> >> The crash only works when I do it on a NFS mounted filesystem. I'm >> using NFSv2/UDP. The server is a 3.2-STABLE FreeBSD box, running >> softupdates on the exported filesystem. I just checked that local >> filesystem on the server, and it is a 100% full. Can this just be put >> down to the known "softupdates full filesystem bug"? Greg> Not based on the (non-existent) evidence you've supplied. Where does Greg> it crash? not having DDB compiled into the kernel I can't answer that. However I'm willing to give any suggestions a go. >> [BTW: the server hasn't crashed, it's only the FreeBSD client that >> crashes] Greg> Do you mean the client process or the client operating system? The client OS -- immediately after creating the symlink. This is the panic I got (taken before Eivind's nfs_vnops.c commit (rev 1.146) : fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code= supervisor read, page not present instruction pointer = 0x8:0xc0163a05 stack pointer = 0x10:0xc9d77e40 code segment = base 0x0; limit 0xf, type 0x1b = DPL0, pres 1, def32.1, gran 1 processor flags = interrupt enabled, resume, 10PL = 0 current process = 1230 (ln) interrupt mask= none trap number = 12 panic: page fault I'm not sure that it helps any... Greg> Greg Viren -- Viren Shah| "You can't trust code that you did not totally Research Associate, RST Inc. | create yourself. (Especially code from [EMAIL PROTECTED] | companies that employ people like me.)" http://www.rstcorp.com/~vshah | - Ken Thompson "Reflections on Trusting Trust" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repeatable crash in -current (softupdates, NFS)
> "Eivind" == Eivind Eklund <[EMAIL PROTECTED]> writes: Eivind> On Sat, Nov 27, 1999 at 10:26:15AM -0500, Viren R.Shah wrote: >> >> I'm running a -current system from Nov 26th (approx 4am EST). >> >> I can currently reliably crash the system by doing: >> >> ln -s /home/users/vshah/public_html/index.html /home/users/vshah/index.html >> >> >> The crash only works when I do it on a NFS mounted filesystem. I'm >> using NFSv2/UDP. The server is a 3.2-STABLE FreeBSD box, running >> softupdates on the exported filesystem. I just checked that local >> filesystem on the server, and it is a 100% full. Can this just be put >> down to the known "softupdates full filesystem bug"? >> >> [BTW: the server hasn't crashed, it's only the FreeBSD client that >> crashes] Eivind> I *think* I know what this is due to - please upgrade Eivind> src/sys/nfs/nfs_vnops.c to revision 1.146 (which I just Eivind> committed) and try again. Tried it. Doesn't work. :-( It still crashes when creating a symbolic link on a NFS mounted filesystem. [This is unfortunate in my case, as it prevents me from running Netscape -- the home dirs are NFS mounted] [vshah@jabberwock] ~> uname -a FreeBSD jabberwock 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sun Nov 28 11:42:23 EST 1999 vshah@jabberwock:/home/ncvs/FreeBSD/current-src/src/sys/compile/J38 i386 2240 [4:36pm] [vshah@jabberwock] ~> grep \$FreeBSD /usr/src/sys/nfs/nfs_vnops.c * $FreeBSD: src/sys/nfs/nfs_vnops.c,v 1.146 1999/11/27 18:14:41 eivind Exp $ Eivind> My bad. Eivind> Eivind. Anything else that springs to mind? Anytihng I can do (diagnostics that I can run) that will help debug this? Viren -- Viren Shah| "You can't trust code that you did not totally Research Associate, RST Inc. | create yourself. (Especially code from [EMAIL PROTECTED] | companies that employ people like me.)" http://www.rstcorp.com/~vshah | - Ken Thompson "Reflections on Trusting Trust" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
At 10:23 PM 11/29/99 +0100, Poul-Henning Kamp wrote: >Ahh, Ok. > >Bruce (a little hasty in my mind) removed a compat shim we had, >please change the 'rda' to 'da' again and all should be fine. > >Poul-Henning Done Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
Ahh, Ok. Bruce (a little hasty in my mind) removed a compat shim we had, please change the 'rda' to 'da' again and all should be fine. Poul-Henning In message <[EMAIL PROTECTED]>, Manfred Antar writes: >At 09:55 PM 11/29/99 +0100, Poul-Henning Kamp wrote: > >>Do you have /dev/sd* in your /etc/fstab ? >> >>It should be changed to /dev/da* >This is what I have > ># DeviceMountpoint FStype Options DumpPass# >/dev/rda0s1bnoneswapsw 0 0 >/dev/rda0s1a/ ufs rw 1 1 >/dev/rda0s1e /var ufsrw 2 2 >/dev/rda0s1f/usrufs rw 2 2 >/dev/rda0s1g /usr/obj ufsrw2 2 >proc/proc procfs rw0 0 >/dev/cd0a /cdrom cd9660 ro,noauto 0 0 > > >Should I change cd0a to rcd0a ? >Any way it boots now with version 1.46 of vfs_conf.c that Mike just committed >Thanks >Manfred >= >||[EMAIL PROTECTED] || >||Ph. (415) 681-6235|| >= > > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
At 09:55 PM 11/29/99 +0100, Poul-Henning Kamp wrote: >Do you have /dev/sd* in your /etc/fstab ? > >It should be changed to /dev/da* This is what I have # DeviceMountpoint FStype Options DumpPass# /dev/rda0s1bnoneswapsw 0 0 /dev/rda0s1a/ ufs rw 1 1 /dev/rda0s1e /var ufsrw 2 2 /dev/rda0s1f/usrufs rw 2 2 /dev/rda0s1g /usr/obj ufsrw2 2 proc/proc procfs rw0 0 /dev/cd0a /cdrom cd9660 ro,noauto 0 0 Should I change cd0a to rcd0a ? Any way it boots now with version 1.46 of vfs_conf.c that Mike just committed Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
Ok, I just tried downloading the IP Filter sources for 3.3.3 and followed the
instructions at http://www.freebsddiary.org/freebsd/ipfilter333.htm.
Unfortunately I have ended up with the same errors:
open device: Device not configured
ioctl(SIOCIPFFL): Bad file descriptor
To reiterate for -CURRENT newsgroup, I'm trying to get IP Filter 3.3.3 to work
in FreeBSD 4.0-CURRENT since it's reinstatement by Guido back into the source
tree. I have the following in my kernel config file:
pseudo-device bpf #Berkeley packet filter
options IPFILTER
options IPFILTER_LOG
#optionsIPFILTER_LKM
#optionsIPFIREWALL
#optionsIPFIREWALL_FORWARD
#optionsIPFIREWALL_VERBOSE
#options"IPFIREWALL_VERBOSE_LIMIT=10"
(Note the lines that are commented out and the lines that aren't.)
I made world and built a new kernel, upon reboot I was greeted with:
Nov 28 20:02:34 /kernel: IP Filter: initialized. Default = pass all, Logging = enabled
Nov 28 20:02:34 /kernel: IP Filter: v3.3.3
But when I try to load any rules, I get the error messages above. Same result
with ipnat. I checked to make sure I was using the right version of ipf:
~# ls -la `which ipf`
-rwxr-xr-x 1 root wheel 28096 Nov 28 19:37 /sbin/ipf
~# ipf -V
ipf: IP Filter: v3.3.3 (192)
open device: Device not configured
ioctl(SIOCGETFS: Bad file descriptor
~# ls -la /dev/ip*
crw-r--r-- 1 root wheel 79, 3 Nov 28 16:27 /dev/ipauth
crw-r--r-- 1 root wheel 79, 0 Nov 28 16:26 /dev/ipl
crw-r--r-- 1 root wheel 79, 1 Nov 28 16:26 /dev/ipnat
crw-r--r-- 1 root wheel 79, 2 Nov 28 16:26 /dev/ipstate
~# truss /sbin/ipf -V | egrep syscall
syscall __sysctl(0xbfbfd62c,0x2,0x18061428,0xbfbfd628,0x0,0x0)
returns 0 (0x0)
syscall mmap(0x0,32768,0x3,0x1002,-1,0x0)
returns 403054592 (0x18062000)
syscall geteuid()
returns 0 (0x0)
syscall getuid()
returns 0 (0x0)
syscall getegid()
returns 0 (0x0)
syscall getgid()
returns 0 (0x0)
syscall open("/var/run/ld-elf.so.hints",0,00)
returns 3 (0x3)
syscall read(0x3,0xbfbfd60c,0x80)
returns 128 (0x80)
syscall lseek(3,0x80,0)
returns 128 (0x80)
syscall read(0x3,0x18066000,0x7c)
returns 124 (0x7c)
syscall close(3)
returns 0 (0x0)
syscall access("/usr/lib/libc.so.4",0)
returns 0 (0x0)
syscall open("/usr/lib/libc.so.4",0,027757753204)
returns 3 (0x3)
syscall fstat(3,0xbfbfd654)
returns 0 (0x0)
syscall read(0x3,0xbfbfc624,0x1000)
returns 4096 (0x1000)
syscall mmap(0x0,581632,0x5,0x2,3,0x0)
returns 403087360 (0x1806a000)
syscall mmap(0x180e4000,20480,0x3,0x12,3,0x79000)
returns 403587072 (0x180e4000)
syscall mmap(0x180e9000,61440,0x3,0x1012,-1,0x0)
returns 403607552 (0x180e9000)
syscall close(3)
returns 0 (0x0)
syscall fstat(1,0xbfbfce10)
returns 0 (0x0)
syscall readlink("/etc/malloc.conf",0xbfbfcdf0,63)
errno 2 'No such file or directory'
syscall mmap(0x0,4096,0x3,0x1002,-1,0x0)
returns 403668992 (0x180f8000)
syscall break(0x8052000)
returns 0 (0x0)
syscall break(0x8056000)
returns 0 (0x0)
syscall open("/dev/ipl",2,027757753004) <<-- Relevant text
errno 6 'Device not configured'
syscall open("/dev/ipl",0,027757753004)
errno 6 'Device not configured'
open device: Device not configured
syscall writev(0x2,0xbfbfd5a0,0x4)
returns 35 (0x23)
syscall ioctl(-1,SIOCGETFS,0xbfbfd614)
errno 9 'Bad file descriptor'
ioctl(SIOCGETFS: Bad file descriptor
syscall writev(0x2,0xbfbfd5d0,0x4)
returns 37 (0x25)
syscall write(1,0x8052000,29)
returns 29 (0x1d)
syscall exit(0x0)
process exit, rval = 0
I got the same result and errors from compiling with the IPFilter present in
the FreeBSD 4.0-CURRENT source tree and from downloading the IP Filter 3.3.3
from it's home page and following the simple instructions at freebsddiary.org.
Misc info:
~# ls -la /dev/bpf*
crw--- 1 root wheel 23, 0 Nov 28 20:02 /dev/bpf0
I have gotten many numerous suggestions and advice from the ipfilter mailing
list, and they have been most helpful in helping me narrow this down, but I
still have not been able to resolve this problem. Does anyone else have any
more hints or tips for me to search? From either IPFilter mailing list or
FreeBSD-CURRENT?
One final note. I updated to the latest snap of -CURRENT from an Oct. 10 snap,
since that was the last date when IP Filter was still in the source tree before
it was removed due to old age. And it worked perfectly then.
Thank you for any help or suggestions.
Davec
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
Manfred, Could you send the 10 lines surrounding the address 0xc014a79a from the output of "nm -n /this_kernel" ? In message <[EMAIL PROTECTED]>, Manfred Antar writes: >Mike >I get a panic on current smp-kernel with the new version >of vfs_conf.c . >The system is current as of this morning >If I back out to version 1.44 it boots fine. >It seems to panic at the swapon part of the boot process. >I get : >Fatal trap 12: page fault while in kernel mode >mp_lock = 0102; cpuid = 1; lapic.id = 0c00 >fault virtual address = 0x2b >fault code = supervisor read, page not present >instruction pointer = 0x8:0xc014a79a >stack pointer = 0x10:0xc0311f34 >frame pointer = 0x10:0xc0311f34 >code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags= interrupt enabled, resume, IOPL = 0 >current process = 0 (swapper) >interrupt mask = none <- SMP: XXX >trap number = 12 >panic: page fault >mp_lock = 0102; cpuid = 1; lapic.id = 0c00 >boot() callled on cpu#1 > >syncing disks .. >= >||[EMAIL PROTECTED] || >||Ph. (415) 681-6235|| >= > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS-UP -- 4.0 alpha klds will need recompiling!
My recent change to the ipl functions in -CURRENT means that alpha kld modules will need to be recompiled before rebooting with a kernel built from version 1.14 or greater of sys/alpha/alpha/ipl_funcs.c. Klds will need to be recompiled because now that the spl functions are inlines, their symbols will not be present in the kernel. This is a good time to rebuild your modules anyway, as pal.s will be going away shortly. Andrew Gallatin writes: > gallatin1999/11/29 12:31:46 PST > > Modified files: > sys/alpha/includeipl.h > sys/alpha/alpha ipl_funcs.c > Log: > inline spl functions. > > In combination with Doug's recent alpha_cpu.h, this reduces the cost > of ipl raising/lowering significantly. This is most pronounced when > doing file reads. Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
At 09:29 PM 11/29/99 +0100, Poul-Henning Kamp wrote: >Manfred, > >Could you send the 10 lines surrounding the address 0xc014a79a >from the output of "nm -n /this_kernel" ? OK This kernel was striped -g do you need a debug compiled kernel ? Here is what i get c014a1c8 T set_timecounter c014a234 t switch_timecounter c014a2b8 t sync_other_counter c014a340 t tco_forward c014a464 t sysctl_kern_timecounter_hardware c014a4f8 T pps_ioctl c014a5dc T pps_init c014a604 T pps_event c014a758 T chrtoblk c014a758 t gcc2_compiled. > this is the closest I got c014a794 T devsw c014a7b0 T cdevsw_add c014a8ac T cdevsw_remove c014a8f8 T major c014a90c T minor c014a920 T lminor c014a940 T makebdev c014a95c T makedev c014aa48 T freedev c014aad0 T dev2udev = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
:Mike :I get a panic on current smp-kernel with the new version :of vfs_conf.c . :The system is current as of this morning :If I back out to version 1.44 it boots fine. :It seems to panic at the swapon part of the boot process. :I get : :Fatal trap 12: page fault while in kernel mode :mp_lock = 0102; cpuid = 1; lapic.id = 0c00 :fault virtual address = 0x2b :fault code = supervisor read, page not present Is the panic occuring with version 1.45 of vfs_conf.c or 1.46? I just committed 1.46 a moment ago along with i386/i386/autoconf.c which fixes BOOTP boots. Prior to that BOOTP boots would panic. A 'trace' would be helpful if you have DDB enabled or, if you are using BOOTP, the problem should now be fixed once the commit propogates. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
At 12:26 PM 11/29/99 -0800, Matthew Dillon wrote: >:Mike >:I get a panic on current smp-kernel with the new version >:of vfs_conf.c . >:The system is current as of this morning >:If I back out to version 1.44 it boots fine. >:It seems to panic at the swapon part of the boot process. >:I get : >:Fatal trap 12: page fault while in kernel mode >:mp_lock = 0102; cpuid = 1; lapic.id = 0c00 >:fault virtual address = 0x2b >:fault code = supervisor read, page not present > > Is the panic occuring with version 1.45 of vfs_conf.c or > 1.46? I just committed 1.46 a moment ago along with > i386/i386/autoconf.c which fixes BOOTP boots. Prior > to that BOOTP boots would panic. > > A 'trace' would be helpful if you have DDB enabled or, > if you are using BOOTP, the problem should now be fixed > once the commit propogates. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> Version 1.46 works fine Thanks Manfred = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP Filter 3.3.3 in FreeBSD -CURRENT [LONG]
No solutions for you, but I have had the same exact problems with
Current and Ip Filter 3.3.3. Giving up.
Current Ip Filter works fine on 3.3-STABLE. Can't hardly wait for 4.0
to be stable and released, I'm not happy with my current mangling of
different compilers in STABLE.
_
Nathan Kinsman
Davec wrote:
>
> Ok, I just tried downloading the IP Filter sources for 3.3.3 and followed the
> instructions at http://www.freebsddiary.org/freebsd/ipfilter333.htm.
> Unfortunately I have ended up with the same errors:
>
> open device: Device not configured
> ioctl(SIOCIPFFL): Bad file descriptor
>
> To reiterate for -CURRENT newsgroup, I'm trying to get IP Filter 3.3.3 to work
> in FreeBSD 4.0-CURRENT since it's reinstatement by Guido back into the source
> tree. I have the following in my kernel config file:
>
> pseudo-device bpf #Berkeley packet filter
> options IPFILTER
> options IPFILTER_LOG
> #optionsIPFILTER_LKM
> #optionsIPFIREWALL
> #optionsIPFIREWALL_FORWARD
> #optionsIPFIREWALL_VERBOSE
> #options"IPFIREWALL_VERBOSE_LIMIT=10"
>
> (Note the lines that are commented out and the lines that aren't.)
> I made world and built a new kernel, upon reboot I was greeted with:
>
> Nov 28 20:02:34 /kernel: IP Filter: initialized. Default = pass all, Logging =
>enabled
> Nov 28 20:02:34 /kernel: IP Filter: v3.3.3
>
> But when I try to load any rules, I get the error messages above. Same result
> with ipnat. I checked to make sure I was using the right version of ipf:
>
> ~# ls -la `which ipf`
> -rwxr-xr-x 1 root wheel 28096 Nov 28 19:37 /sbin/ipf
>
> ~# ipf -V
> ipf: IP Filter: v3.3.3 (192)
> open device: Device not configured
> ioctl(SIOCGETFS: Bad file descriptor
>
> ~# ls -la /dev/ip*
> crw-r--r-- 1 root wheel 79, 3 Nov 28 16:27 /dev/ipauth
> crw-r--r-- 1 root wheel 79, 0 Nov 28 16:26 /dev/ipl
> crw-r--r-- 1 root wheel 79, 1 Nov 28 16:26 /dev/ipnat
> crw-r--r-- 1 root wheel 79, 2 Nov 28 16:26 /dev/ipstate
>
> ~# truss /sbin/ipf -V | egrep syscall
> syscall __sysctl(0xbfbfd62c,0x2,0x18061428,0xbfbfd628,0x0,0x0)
> returns 0 (0x0)
> syscall mmap(0x0,32768,0x3,0x1002,-1,0x0)
> returns 403054592 (0x18062000)
> syscall geteuid()
> returns 0 (0x0)
> syscall getuid()
> returns 0 (0x0)
> syscall getegid()
> returns 0 (0x0)
> syscall getgid()
> returns 0 (0x0)
> syscall open("/var/run/ld-elf.so.hints",0,00)
> returns 3 (0x3)
> syscall read(0x3,0xbfbfd60c,0x80)
> returns 128 (0x80)
> syscall lseek(3,0x80,0)
> returns 128 (0x80)
> syscall read(0x3,0x18066000,0x7c)
> returns 124 (0x7c)
> syscall close(3)
> returns 0 (0x0)
> syscall access("/usr/lib/libc.so.4",0)
> returns 0 (0x0)
> syscall open("/usr/lib/libc.so.4",0,027757753204)
> returns 3 (0x3)
> syscall fstat(3,0xbfbfd654)
> returns 0 (0x0)
> syscall read(0x3,0xbfbfc624,0x1000)
> returns 4096 (0x1000)
> syscall mmap(0x0,581632,0x5,0x2,3,0x0)
> returns 403087360 (0x1806a000)
> syscall mmap(0x180e4000,20480,0x3,0x12,3,0x79000)
> returns 403587072 (0x180e4000)
> syscall mmap(0x180e9000,61440,0x3,0x1012,-1,0x0)
> returns 403607552 (0x180e9000)
> syscall close(3)
> returns 0 (0x0)
> syscall fstat(1,0xbfbfce10)
> returns 0 (0x0)
> syscall readlink("/etc/malloc.conf",0xbfbfcdf0,63)
> errno 2 'No such file or directory'
> syscall mmap(0x0,4096,0x3,0x1002,-1,0x0)
> returns 403668992 (0x180f8000)
> syscall break(0x8052000)
> returns 0 (0x0)
> syscall break(0x8056000)
> returns 0 (0x0)
> syscall open("/dev/ipl",2,027757753004) <<-- Relevant text
> errno 6 'Device not configured'
> syscall open("/dev/ipl",0,027757753004)
> errno 6 'Device not configured'
> open device: Device not configured
> syscall writev(0x2,0xbfbfd5a0,0x4)
> returns 35 (0x23)
> syscall ioctl(-1,SIOCGETFS,0xbfbfd614)
> errno 9 'Bad file descriptor'
> ioctl(SIOCGETFS: Bad file descriptor
> syscall writev(0x2,0xbfbfd5d0,0x4)
> returns 37 (0x25)
> syscall write(1,0x8052000,29)
> returns 29 (0x1d)
> syscall exit(0x0)
> process exit, rval = 0
>
> I got the same result and errors from compiling with the IPFilter present in
> the FreeBSD 4.0-CURRENT source tree and from downloading the IP Filter 3.3.3
> from it's home page and following the simple instructions at freebsddiary.org.
>
> Misc info:
> ~# ls -la /dev/bpf*
> crw--- 1 root wheel 23, 0 Nov 28 20:02 /dev/bpf0
>
> I have gotten many numerous suggestions and advice from the ipfilter mailing
> list, and they have been most helpful in helping me narrow this down, but I
> still have not been able to resolve this problem. Does anyone else have any
> more hints or tips for me to search? From either IPFilter mailing list or
> FreeBSD-CURRENT?
>
> One final note. I
Re: New vfs_conf.c panic
Do you have /dev/sd* in your /etc/fstab ? It should be changed to /dev/da* In message <[EMAIL PROTECTED]>, Manfred Antar writes: >At 09:29 PM 11/29/99 +0100, Poul-Henning Kamp wrote: > >>Manfred, >> >>Could you send the 10 lines surrounding the address 0xc014a79a >>from the output of "nm -n /this_kernel" ? >OK >This kernel was striped -g >do you need a debug compiled kernel ? >Here is what i get >c014a1c8 T set_timecounter >c014a234 t switch_timecounter >c014a2b8 t sync_other_counter >c014a340 t tco_forward >c014a464 t sysctl_kern_timecounter_hardware >c014a4f8 T pps_ioctl >c014a5dc T pps_init >c014a604 T pps_event >c014a758 T chrtoblk >c014a758 t gcc2_compiled. > > > this is the closest I got > >c014a794 T devsw >c014a7b0 T cdevsw_add >c014a8ac T cdevsw_remove >c014a8f8 T major >c014a90c T minor >c014a920 T lminor >c014a940 T makebdev >c014a95c T makedev >c014aa48 T freedev >c014aad0 T dev2udev >= >||[EMAIL PROTECTED] || >||Ph. (415) 681-6235|| >= > > -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New vfs_conf.c panic
:c014a794 T devsw :c014a7b0 T cdevsw_add c014a79a --- sounds like the same or a similar bug to the one I fixed, where devsw() was being called with rootdev == NODEV (-1) and doing a NULL (well -1) pointer dereference. In my case it was related to an assumption at line 203 of vfs_conf.c in vfs_mountroot_try() that rootdev had been initialized. This isn't the case for a BOOTP boot. I do not know about other types of booting. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New vfs_conf.c panic
Mike I get a panic on current smp-kernel with the new version of vfs_conf.c . The system is current as of this morning If I back out to version 1.44 it boots fine. It seems to panic at the swapon part of the boot process. I get : Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = 0c00 fault virtual address = 0x2b fault code = supervisor read, page not present instruction pointer = 0x8:0xc014a79a stack pointer = 0x10:0xc0311f34 frame pointer = 0x10:0xc0311f34 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) interrupt mask = none <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = 0c00 boot() callled on cpu#1 syncing disks .. = ||[EMAIL PROTECTED] || ||Ph. (415) 681-6235|| = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: State of Alpha support and Oracle.
> http://www.relex.ru/linter/ This looks pretty neat. Has anybody actually used this under FreeBSD? Any comments? One of the tricky things about selecting FreeBSD software is how commited the vendor is towards the OS. I'd hate to commit to something like this and then have the vendor stop supporting FreeBSD in the future. Thanks, Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
MAKEDEV & newpcm driver
So, is the right command to make the audio device entries ./MAKEDEV snd0, or does newpcm have a different method to create the audio device entries? Also, I have an ESS 1868, and I'm getting the "fast forward" effect with the newpcm driver. It's a SB compatible card. I'll attach the output of dmesg. -- - Donn Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Mon Nov 29 13:40:20 EST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/CUSTOM Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (166.45-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bf real memory = 62914560 (61440K bytes) avail memory = 57962496 (56604K bytes) Preloaded elf kernel "kernel" at 0xc02f5000. Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 ide_pci0: irq 11 at device 1.1 on pci0 ed0: irq 10 at device 10.0 on pci0 ed0: address 00:c0:df:ed:0b:17, type NE2000 (16 bit) vga-pci0: irq 11 at device 19.0 on pci0 devclass_alloc_unit: ed0 already exists, using next available unit number fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 3093MB (6335280 sectors), 6704 cyls, 15 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , DMA, 32-bit, multi-block-16 wd1: 1040MB (2130912 sectors), 2114 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa0 wdc1: unit 0 (atapi): , removable, accel, dma, iordy wcd0: drive speed 515 - 1718KB/sec, 128KB cache wcd0: supported read types: CD-DA wcd0: Audio: play, 255 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: CD-ROM 120mm data disc loaded, unlocked atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 mse0 at port 0x23c irq 3 on isa0 vga0: at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0: not probed (disabled) sio1: not probed (disabled) sio2 at port 0x3e8-0x3ef irq 4 on isa0 sio2: type 16550A ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 unknown0: at port 0x800-0x807 on isa0 pcm0: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 unknown1: at port 0x201 on isa0 Mounting root from ufs:/dev/wd0s1a
More newpcm breakage
My SB32 PnP, which had so far worked nicely with newpcm except for the "fast forward" bug, stopped working after the newmidi import. This means that none of my sound cards (except for the GUS PnP, which I haven't tested) work any more, and I am seriously losing faith in the authors' ability to maintain a device driver. I've attached the output of dmesg and pnpinfo from the affected box, both with and without the PNPBIOS option. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #17: Wed Nov 24 20:31:13 CET 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/NIOBE Calibrating clock(s) ... TSC clock: 166192956 Hz, i8254 clock: 1193180 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium/P54C (166.19-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x002e5000 - 0x07ff7fff, 131149824 bytes (32019 pages) avail memory = 126554112 (123588K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f8630 bios32: Entry = 0xf8080 (c00f8080) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x80b0 pnpbios: Found PnP BIOS data at 0xc00fc730 pnpbios: Entry = f:c760 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc02cc000. Intel Pentium detected, installing workaround for F00F bug VESA: information block 56 45 53 41 00 02 d9 6c 00 c0 00 00 00 00 22 00 00 01 24 00 00 00 eb 6c 00 c0 eb 6c 00 c0 eb 6c 00 c0 00 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 0c 01 22 01 24 01 2a 01 1d 01 VESA: 52 mode(s) found VESA: v2.0, 2304k memory, flags:0x0, mode table:0xc027d742 (122) VESA: Tseng Labs ET6000 VESA: pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12508086) npx0: on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 173731758 bytes/sec bzero() bandwidth = 736377025 bytes/sec pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=12508086) pcib0: on motherboard found-> vendor=0x8086, dev=0x1250, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 found-> vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found-> vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base e800, size 4 found-> vendor=0x100c, dev=0x3208, revid=0x70 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base f900, size 24 map[14]: type 1, range 32, base e000, size 8 found-> vendor=0x8086, dev=0x1229, revid=0x02 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base fa80, size 12 map[14]: type 1, range 32, base d800, size 5 map[18]: type 1, range 32, base f880, size 20 found-> vendor=0x9004, dev=0x8178, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=12 map[10]: type 1, range 32, base d400, size 8 map[14]: type 1, range 32, base f800, size 12 pci0: on pcib0 i4b_pci_probe: unknown PCI type 307265670l! isab0: at device 7.0 on pci0 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: IRQ12, B: disabled, C: IRQ9, D: IRQ9 MB0: IRQ15, MB1: isa0: on isab0 ata-pci0: at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0: iobase=0x01f0 altiobase=0x03f6 ata0: mask=03 status0=50 status1=00 ata0: mask=03 status0=50 status1=00 ata0: devices = 0x1 ata0 at 0x01f0 irq 14 on ata-pci0 ata1: iobase=0x0170 altiobase=0x0376 ata1: mask=00 status0=fe status1=fe i4b_pci_probe: unknown PCI type 839389196l! vga-pci0: irq 9 at device 9.0 on pci0 fxp0: irq 9 at device 10.0 on pci0 fxp0: Ethernet address 00:a0:c9:4d:1b:d4 bpf: fxp0 attached ahc0: irq 12 at device 12.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: internal 50 cable is present, internal 68 cable is present ahc0: external cable not present
Re: HEADS UP, bind update shortly...
> I'm about to import bind 8.2.2.p5 into src/contrib/bind and fix up the > broken parts of the tree as I go. I will disable the named (and associated > tools) build for the duration. If you want to do some make worlds or > releases in the next 8 hours or so, do a cvsup pronto! Thanks Peter! Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
< said: > The route disappears from the routing table, but it is > not freed. (The Leak.) Actually, no. > Now cause some packets to travel on the connection. A new cloned > route is created and added to the routing table. Here is where the leak happens, as demonstrated by your patch. (Great detective work, BTW.) > 1. Do I really need the splnet calls around RTFREE? I don't think so. All calls into the routing code should already be protected by splnet. We may have to revisit this in the future for finer-grained locking. > 2. To eliminate all the duplicated code, shall I make rtalloc just > call rtalloc_ign(ro, 0UL)? I assume that was avoided originally for > performance reasons, but now there's more code than before. Actually, it was avoided originally because it was easier to just cut and paste. There is no inherent reason for the duplication, although Matt's suggestion of topologically sorting the routines so that GCC will have a chance at inlining is not a bad one. (I'd actually like to find all the calls to rtalloc() and simply add an extra argument to them. I can't fathom why I didn't do that five years ago) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: loader.conf, ordering of loading of modules
Nick Hibma wrote: > > Is it possible to change the order in which modules are loaded in > loader.conf? I need usb before uhci before ums. > > usb_load="YES" > uhci_load="YES" > ums_load="YES" > > doesn't do it. Funny, I thought they were loaded in the order they were declared. Alas, I'm not inclined to add any kind of ordering of module loading, because this ought to be handled by the load/linking functions and module-declared dependencies. Let's not fix the wrong thing. -- Daniel C. Sobral(8-DCS) who is as social as a wampas [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP, bind update shortly...
Peter Wemm wrote: > I'm about to import bind 8.2.2.p5 into src/contrib/bind and fix up the > broken parts of the tree as I go. I will disable the named (and associated > tools) build for the duration. If you want to do some make worlds or > releases in the next 8 hours or so, do a cvsup pronto! Sorry, this is on hold for a little longer. I thought the lib/dnssafe and lib/cylink license and export issues had been resolved, but I'm not so sure now. I'm waiting on more info. named does seem to run happily with the dnssafe (rsa crypto library) removed though, so it should still be possible to update it even if the dnssafe and/or cylink code has to go. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
:> :> Yes. Because the route table may be flushed from an interrupt in :> a low memory situation. : :I guess I didn't state the question very well. I realize that RTFREE :has to be executed at splnet. But I think it's likely that rtalloc :and rtalloc_ign are always called at splnet or better. If that's the :case and it's already required, then adding the redundant splnet calls :would be obfuscatory. I'd rather add a comment instead. I ran across this situation in a number of places while fixing the VM system. If you want to get rid of the splnet() calls you have to document the procedure containing the calls in the comments above the procedure, adding something like: /* * fubar: fubar the kernel * * This procedure must be called at splnet() * This procedure does not block * This procedure must */ And then make sure that all calls to the procedure indeed occur at splnet(). Then you can get rid of the splnet() calls within the procedure. For examples of the type of documentation necessary, look at vm/swap_pager.c. So what it comes down to are the requirements you wish to impose on the official use of the procedure. Note that making spl*() calls when the current process is already at that spl level do not impose any real overhead. : :John :-- : John Polstra [EMAIL PROTECTED] -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Route table leaks
In article <[EMAIL PROTECTED]>, Matthew Dillon <[EMAIL PROTECTED]> wrote: > :1. Do I really need the splnet calls around RTFREE? > > Yes. Because the route table may be flushed from an interrupt in > a low memory situation. I guess I didn't state the question very well. I realize that RTFREE has to be executed at splnet. But I think it's likely that rtalloc and rtalloc_ign are always called at splnet or better. If that's the case and it's already required, then adding the redundant splnet calls would be obfuscatory. I'd rather add a comment instead. > :2. To eliminate all the duplicated code, shall I make rtalloc just > :call rtalloc_ign(ro, 0UL)? I assume that was avoided originally for > :performance reasons, but now there's more code than before. > : > Hmm. One trick I used in the VM code was to put the common code in an > inline static function and leave the external functions broken out to > avoid an unnecessary call chain. OK, that's a possibility. I was hoping our network-meister (Yo, Garrett!) would give me a sign as to whether it would be worthwhile or not. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
BOOTP appears to be broken again
Hmm. BOOTP appears to be broken again in current My diskless systems are insisting on mounting root from fd0c with the latest current (verses one about a month ago). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe zoso@accessus.net
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP, bind update shortly...
I'm about to import bind 8.2.2.p5 into src/contrib/bind and fix up the broken parts of the tree as I go. I will disable the named (and associated tools) build for the duration. If you want to do some make worlds or releases in the next 8 hours or so, do a cvsup pronto! Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI project progress report - Nov.
Hi, here is the Nov. progress report from ACPI project in Japan.
1. Summary of our activities in this month:
- setup CVS repository and CVSup collection for developing
environment (jp-acpi collection on cvsup.jp.FreeBSD.org).
- improve device driver (S1 and S5 state transition are supportted
on several machines).
- gather ASL code and DSDT data (not so many, but still useful to
design AML interpreter).
- start AML interpreter developing (now it is in the userland, then
move it to kernel space later).
2.ACPI CVS repository and CVSup
To CVSup acpi development source tree, please try this configuration.
---
*default host=cvsup.jp.FreeBSD.org
*default base=/usr
*default prefix=/home/cvs
*default release=cvs
*default delete use-rel-suffix
jp-acpi
#jp-all
---
Other CVSup servers (such as cvsup2.jp.FreeBSD.org) are also available.
3. ACPI device driver progress:
- detect ACPI BIOS and install the interrupt handler.
- experimental support S1 (sleeping state 1) and S5 (soft off).
- have abilities to detect and handle power/sleep button press event.
- add builtin PTS (prepare to sleep) control method for several
machines. this is temporary until finish AML interpreter development.
- set sleeping state via ioctl.
Yes, now it's possible that shutdown and power machine off by power
button, but only work for the limited number of supported machines.
Difficulty is to get value of \_Sx package and parse/execute \_PTS
method, so our tentative solution is to have builtin PTS functions for
the machines using bogos macros :-) Stupid? yes I think so too.
We've started discussing AML interpreter implementation.
4. ASL code and DSDT data collection
We are gathering them for further design and implementation.
CVSup ACPI source tree, compile ACPI/util/ tools, then
% cd ACPI/util/dfr/acpitest/
% ./acpitest >foo.asl
% cd ACPI/util/takawata/acpi/
% ./acpitblrd foo.dsdt.dat
>^D
%
and finally send them to [EMAIL PROTECTED]
Submitted data will be stored in ACPI CVS repository.
5. AML interpreter implementation
We've just started based on Doug Rabson's acpitest program, but
parsing AML and managing objects in the name space are almost
finished. We're going to make configuration utility first with AML
interpreter in the userland, then move it to kernel space after brush
it out.
Please see
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/util/acpiconf?cvsroot=freebsd-jp
In the beginning of this project, we thought merging them to
4.0-RELEASE would be very much exciting, but it seems the codes are
still young to merge and 4.0-RELEASE feature freeze is comming soon.
We will try another chance, hopefully we have AML interpreter in
kernel space at that time.
Attached diffs are the latest acpi device driver against -current.
# cd /usr/src
# mkdir sys/i386/acpi
# patch < this_patch
Suggestions, ideas, patches, bug reports, rewriting the codes, offer
of cooperation/volunteers and others are very appreciated.
Thanks!
begin 644 acpi-sys-19991129.diff.gz
M'XL(")N40C@``V%C<&DM94[M5IMF\XE<[H@?[<]0IJD\?#!U)K5!MDKUEMOGGSDGSXL+.W_Z*VLT=>D+8?
MW(?N]30F9:?"P(EIW]B>'[KDTHYMSQY3\CZ&JEOX^A!-W8D]M4.[60]FMD?C
M>N2X]1M_3&N+NNW4_QT<%Z&]<.-H$2Z(?MDR6K_IY+U[:T?VC?OA-*3TQ.C4
M_?":=V[-9H1UCDA((QHNZ:2.#:QQ2"=N%(?N>!&[P+#M3<@BHL3U2.0O0H>R
MFK'KV>$]N?+#>50EMVX\)7[(_O87,4,S]R?NE>O8B*1*[)"2@(9S-X[IA`2A
MOW0G4(BG=@R_*"":S?Q;U[LFCN]-7.P4,338<4[C=^RC65^A+B+^E23+\2<`
MNHABX"FV@5S$:X_])38)83$L\./YL>O0*H"X$9D!0L23CLQ8S)(%HSHSVYW3
MD$F*'*R3`D,J8I&D`*^3!9#W)U%#.*,2U<1W%G-0>5O.W3Y,BP\`(9G;,0U=
M>Q:EXF?SAIA51E)-,,]U@QC]4_.R-=0(E`?#_D>]HW7(R6=HU$AK9)[WAZ35
MZY!VOV<.]9.1V1\:Y%__:AD`_[>_81/7N-YGHGT:##7#(-!#OQAT=<`#B(>M
MGJEK1I7HO79WU-%[9U4":$BO;Y*N?J&;`&;VJS@>P[3>E?1/R84V;)_#9^M$
M[^KF9T;2J6[V<+Q3))$,6D-3;X^ZK2$9C(:#OL'1(6<=W6AW6_J%UJD3(`.&
M)MI'K6<2X[S5[:J&
MJ9LC4R-G_7['8+A@`$,;?M3;FG%(NGV#"6UD:%48Q6PQ`@`-2`R:H7PR,G0F
M.[UG:L/A:&#J_5Z%83KO7X)P@-X6=.\P0?=[C&V04W_X&1&C3-@\5,GEN0;U
M0Q0KDUP+Q6&`!-LF0Z>`PK@@5%/AE_2TLZY^IO7:&K;V$=.E;F@5F#;=0`"=
M#WW9^LS9'#$1X(P!=;RHZ'"5S2O13TFK\U%'\@4PJ(.A"]7IGS)4QJA]+J8@
M71%_%:;TK_BUO[/WD^LYLP78G5T_B"VV34QWE>KWN(\$8,WG]>GQ6GWH.SG5
M\'^S6N8VV!.5BE8SO>7JZ-#73"W@Y7:
MN>U,78_N.X#DIJ!M/K&6]BJULC&BUVBJHJ+F>&*'UP6-<534;3G/D[=L#9S]
ML>L7]856/H>95C>R]P,O"&D1,>-%$4+87=GFE"/]34USV\NI7A\&:V&?N&+5
MZ')PD]8>Z`0GC$2+,6H3G4MUG=`K((M!6,9%:V!=M#Y9AOY_&F$_S3>(!K:"
MA1,S('LR"A2Z-#^!0@V%):SBW_ZBJBL167`ML:VQ$]7*U?
M9NLC][\4:O$O5K6P`/_+`ZB*[P-6]9W$Y,LZF5^A[?LA)Q*V.((*9K$Y`7@B`]SZJ^@GU)_"@UC?W+/&RPLYO6:9+%!+P/
Re: repeatable crash in -current (softupdates, NFS)
On Saturday, 27 November 1999 at 10:26:15 -0500, Viren R.Shah wrote: > > I'm running a -current system from Nov 26th (approx 4am EST). > > I can currently reliably crash the system by doing: > > ln -s /home/users/vshah/public_html/index.html /home/users/vshah/index.html > > > The crash only works when I do it on a NFS mounted filesystem. I'm > using NFSv2/UDP. The server is a 3.2-STABLE FreeBSD box, running > softupdates on the exported filesystem. I just checked that local > filesystem on the server, and it is a 100% full. Can this just be put > down to the known "softupdates full filesystem bug"? Not based on the (non-existent) evidence you've supplied. Where does it crash? > [BTW: the server hasn't crashed, it's only the FreeBSD client that > crashes] Do you mean the client process or the client operating system? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm - I can only get noice from it
My collegue just made my day :-) device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x15 did it. /Jesper On Mon, Nov 29, 1999 at 03:22:45PM +0100, Jesper Skriver wrote: > Hi, > > Just managed to get hold of a old Soundblaster 16 card, but I can only > get noice from it when I try to play som mp3 files ... > > It's found upon boot like > > pcm0: at port 0x220-0x22f irq 5 drq 1 on isa0 > > I have it wired in the kernel config file, if I don't it wont find it (I > have controller pnp0 in there too), it's like > > device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x0 > > Any ideas ? > > /Jesper > > -- > Jesper Skriver (JS4261-RIPE), Network manager > Tele Danmark DataNet, IP section (AS3292) > > One Unix to rule them all, One Resolver to find them, > One IP to bring them all and in the zone to bind them. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm - I can only get noice from it
Hi, Just managed to get hold of a old Soundblaster 16 card, but I can only get noice from it when I try to play som mp3 files ... It's found upon boot like pcm0: at port 0x220-0x22f irq 5 drq 1 on isa0 I have it wired in the kernel config file, if I don't it wont find it (I have controller pnp0 in there too), it's like device pcm0 at isa? port 0x220 irq 5 drq 1 flags 0x0 Any ideas ? /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Soulness.com - Open your mind and free your soul
Hello, my name is Azani Sanchez, Senior Editor of Soulness.com. 6 months ago I started Soulness.com as a senior in my dorm at Howard University in Washington, DC. I would like to invite you to visit www.soulness.com and join our online community, and take a look for yourself and see what we have to offer Here’s just a sample of what we have to help, stimulate your mind, your body and your soul: Girltalk - A place where women can get together andtalk about the issues.Membaz Area (Photos) - Meet the love of your life orPen PalsLive Chat- Talk and meet new friends from around theplanet.Tha 411- Entertainment news and information coveringour worldBanging Joints- Hip-Hop & R&B countdown.UrbanFashion- Threads for tha Streets If you like the site, please tell a friend..
Re: gcc 2.95.2 breaks imake
> I have just noticed that the new gcc breaks imake because > /usr/libexec/cpp doesn't define __FreeBSD__. What is the plan to fix > everything in this area? Yes. The issue is known. I'm not happy with my choices of fixing this. > The 2 options I can see is to revert the behaviour of cpp, Nope. Doing so would add yet more differences from GCC code. > or find everything that uses cpp and change them to use cc -E. For now, that is the best approach. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compiling drivers as lkm's
> Is there any kernel config option that can be used to link a driver to the > kernel dynamically (LKM) instead of statically? LKM's are out-dated. We now have the 2nd generation KLD (Kernel Loader) modules. > Of course, if anyone has any links or info on how to write a driver > period, I'd like to know. /usr/share/examples/kld/* > It seems like the best method to write, test, and debug a new driver would > be to use lkm's, since you could just use kldload() and kldunload() to > test the driver-in-progress instead of just rebooting. Yes. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH] Four patches for review and test
Four patches for review and test. They are for 4.0-CURRENT. (moused patch should also work with -STABLE too.) http://www.freebsd.org/~yokota/moused-991129.diff http://www.freebsd.org/~yokota/kbdcontrol-991129.diff http://www.freebsd.org/~yokota/panickey-991129.diff http://www.freebsd.org/~yokota/altlock-991129.diff Kazu [EMAIL PROTECTED] Patch #1. moused: the -3 option (moused-991129.diff) The three-button emulation of the mouse daemon has been somewhat difficult to use for many people. This patch will try to improve the situation by introdusing a small state machine. There is a new option, -E, to set timeout value to detect two buttons are pressed down simulteneously. The default value for this timeout is 200 msec. The patch should work with both 4.0-CURRENT and 3.3-STABLE. cd /usr/src/usr.sbin/moused patch < moused-991129.diff Patch #2. kbdcontrol (kbdcontrol-991129.diff) The patch will add a few new key definitions. This patch is required for the patches 3 and 4 below. cd /usr/src patch < kbdcontrol-991129.diff Patch #3. Panic key (panickey-991129.diff) The patch adds "panic key" function to syscons. When this key is defined in a keymap and pressed, the system panic will be forced. As this can be a security problem, this feature must be specifically enabled by a new sysctl variable: machdep.enable_panic_key. The default value is 0. The panic key won't do anything unless this variable is set to non-zero. To use the panic key, add a keyword 'panic' to a key in your keymap file. The following example assigns the panic function to SysReq (Alt-PrintScreen) key (keycode 84). 083 del'.''.''.''.''.'boot bootN 084 panic nopnopnoppanic nopnopnop O 085 nopnopnopnopnopnopnopnop O The patch requires the patch #2 above. Related PR: kern/13721 cd /sys/dev/syscons patch < panickey-991129.diff Patch #4. Adding AltLock function to shift keys (altlock-991129.diff) Our keymap may contain AltLock (alock) or AltShift (ashift) keys. This patch will add new keys: lshifta, rshifta, lctrla, rctrla, lalta, and ralta. These keys combine shift/ctrl/alt function and the AltLock function. When these keys pressed together with another key, they act just like the ordinary shift/ctrl/alt keys. When these keys are pressed and released alone, Alt state is locked/unlocked. Related PR: kern/12475 cd /sys/dev/kbd patch < altlock-991129.diff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Compiling drivers as lkm's
Is there any kernel config option that can be used to link a driver to the kernel dynamically (LKM) instead of statically? Also, I'd like to know how to write a driver as an lkm. Of course, if anyone has any links or info on how to write a driver period, I'd like to know. It seems like the best method to write, test, and debug a new driver would be to use lkm's, since you could just use kldload() and kldunload() to test the driver-in-progress instead of just rebooting. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
