Re: 100% system time? (SMPng on UP system)
On 16 Sep, John Baldwin wrote: None of the CPU states from vmmeter are close to accurate on UP x86 systems at the moment because statclock() doesn't have a valid stack frame to work with. SMP is slightly more accurate as we get all the stats on the other CPU's correct. This is on the todo list to fix, but it is merely cosmetic, so it is farther down on the list than, say, finishing up threading interrupts on the alpha. :) It wasn't mentioned in the known bugs list, so I thought it wasn't known. BTW: Good work, keep going on. Bye, Alexander. -- Intel: where Quality is job number 0.9998782345! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for openssh
On 16 Sep, To: [EMAIL PROTECTED] wrote:
But I think I found some other bugs, please have a look at the attached
diff.
Oops, sorry, wrong diff.
Bye,
Alexander.
--
To boldly go where I surely don't belong.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
Index: authfd.c
===
RCS file: /big/FreeBSD-CVS/src/crypto/openssh/authfd.c,v
retrieving revision 1.6
diff -u -r1.6 authfd.c
--- authfd.c2000/09/10 09:35:37 1.6
+++ authfd.c2000/09/16 15:27:25
@@ -178,7 +178,7 @@
if (sock 0)
return NULL;
- auth = xmalloc(sizeof(*auth));
+ auth = xmalloc(sizeof(AuthenticationConnection));
auth-fd = sock;
buffer_init(auth-identities);
auth-howmany = 0;
Index: ssh-agent.c
===
RCS file: /big/FreeBSD-CVS/src/crypto/openssh/ssh-agent.c,v
retrieving revision 1.7
diff -u -r1.7 ssh-agent.c
--- ssh-agent.c 2000/09/10 09:35:38 1.7
+++ ssh-agent.c 2000/09/17 09:24:21
@@ -577,6 +577,8 @@
perror("accept from AUTH_SOCKET");
break;
}
+ slen -= sizeof(sunaddr.sun_len) +
+sizeof(sunaddr.sun_family);
+ sunaddr.sun_path[slen] = 0;
new_socket(AUTH_CONNECTION, sock);
}
break;
@@ -741,7 +743,8 @@
memset(sunaddr, 0, sizeof(sunaddr));
sunaddr.sun_family = AF_UNIX;
strlcpy(sunaddr.sun_path, socket_name, sizeof(sunaddr.sun_path));
- if (bind(sock, (struct sockaddr *) sunaddr, sizeof(sunaddr)) 0) {
+ sunaddr.sun_len = SUN_LEN(sunaddr)+1;
+ if (bind(sock, (struct sockaddr *) sunaddr, sunaddr.sun_len) 0) {
perror("bind");
cleanup_exit(1);
}
Re: fxp suspend/resume hangs
in summary: PR kern/18756 contains a patch (against -stable, alas, This PR has been explicitly assigned to David Greenman and should be handled by him. As I pointed out in another message, nobody but he is likely to touch the fxp driver under any circumstances so it basically comes down to either him or nobody. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On 17 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
Bye,
Alexander.
--
There's no place like ~
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
appended below is an excerpt from a message sent to -stable earlier tonight, containing content of a type which kris kenneway correctly suggested would find a more suitable audience on -current. in summary: PR kern/18756 contains a patch (against -stable, alas, sorry) which fixes kernel hangs in the fxp driver on some laptops after a resume from suspend. while quite a few people appear to be using this patch successfully, it hasn't been committed -- david greenman had an entirely reasonable objection to one aspect of the patch's behavior. unfortunately, my knowledge of the kernel isn't sufficient to adequately address david's concerns, and though i've mailed him to ask for guidance twice over the past 4 months, i haven't received a response. that's probably my fault, i probably should have been mailing -current to being with. I can only find the 5/22 email regarding this, so I seem to have missed your second message. With over a thousand emails a day coming into my inbox, this shouldn't be too surprising. My response to the 5/22 message was this: ... This could be a problem. If an interrupt occurs, it must be acknowledged otherwise you'll be stuck in an infinit loop - PCI interrupts are level sensitive and must be cleared in the ISR. ... In short, while it may fix a hang in your laptop case, it opens the driver up to a hang if an unexpected interrupt occurs while IFF_RUNNING is clear. I think this is dangerous enough that I don't think the code should not be compiled as part of the standard driver. One just cannot ignore level- sensitive PCI interrupts. if anybody can offer any suggestions as to how to move forward with getting this patch to the point where it can be committed, i'd certainly appreciate it. alternately, any feedback on whether the patch is necessary and/or functional on your machine, laptop or no, would be interesting. i wouldn't be at all surprised if there were a better approach than simply ignoring interrupts when the device isn't running, but it's not clear to me what that would be. if anybody has any suggestions as to how to clean this up, i'm all ears. alternately, if any committers want to take this on, that'd be swell too. Someone needs to find out what the laptop is doing to the STATACK register that causes a hang when it is accessed. Failing any better resolution, I guess that the objected-to change could be committed with an ifdef. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
I've made a few changes to the patches which should address my primary
concerns. Instead of using IFF_RUNNING, I added a new softc variable to
track the suspended condition. Only the APM stuff should call suspend/resume,
so the interrupt logic should be uneffected in non-APM machines. Please try
these patches out and let me know if they work as expected. They should apply
and work with both -stable and -current.
-DG
David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.
Index: if_fxp.c
===
RCS file: /home/ncvs/src/sys/pci/if_fxp.c,v
retrieving revision 1.77.2.3
diff -c -r1.77.2.3 if_fxp.c
*** if_fxp.c2000/06/19 00:54:30 1.77.2.3
--- if_fxp.c2000/09/17 13:15:33
***
*** 125,135
--- 125,139
fxp_lwcopy(src, dst)
volatile u_int32_t *src, *dst;
{
+ #ifdef __i386__
+ *dst = *src;
+ #else
volatile u_int16_t *a = (volatile u_int16_t *)src;
volatile u_int16_t *b = (volatile u_int16_t *)dst;
b[0] = a[0];
b[1] = a[1];
+ #endif
}
/*
***
*** 215,220
--- 219,225
static void fxp_mediastatus __P((struct ifnet *, struct ifmediareq *));
static void fxp_set_media __P((struct fxp_softc *, int));
static __inline void fxp_scb_wait __P((struct fxp_softc *));
+ static __inline void fxp_dma_wait __P((volatile u_int16_t *, struct fxp_softc *sc));
static FXP_INTR_TYPE fxp_intr __P((void *));
static void fxp_start __P((struct ifnet *));
static int fxp_ioctl __P((struct ifnet *,
***
*** 283,290
struct fxp_softc *sc;
{
int i = 1;
! while (CSR_READ_1(sc, FXP_CSR_SCB_COMMAND) --i);
}
/*
--- 288,311
struct fxp_softc *sc;
{
int i = 1;
+
+ while (CSR_READ_1(sc, FXP_CSR_SCB_COMMAND) --i)
+ DELAY(2);
+ if (i == 0)
+ printf(FXP_FORMAT ": SCB timeout\n", FXP_ARGS(sc));
+ }
+
+ static __inline void
+ fxp_dma_wait(status, sc)
+ volatile u_int16_t *status;
+ struct fxp_softc *sc;
+ {
+ int i = 1;
! while (!(*status FXP_CB_STATUS_C) --i)
! DELAY(2);
! if (i == 0)
! printf(FXP_FORMAT ": DMA timeout\n", FXP_ARGS(sc));
}
/*
***
*** 679,690
--- 700,784
return 0;
}
+ /*
+ * Device suspend routine. Stop the interface and save some PCI
+ * settings in case the BIOS doesn't restore them properly on
+ * resume.
+ */
+ static int
+ fxp_suspend(device_t dev)
+ {
+ struct fxp_softc *sc = device_get_softc(dev);
+ int i, s;
+
+ s = splimp();
+
+ fxp_stop(sc);
+
+ for (i=0; i5; i++)
+ sc-saved_maps[i] = pci_read_config(dev, PCIR_MAPS + i*4, 4);
+ sc-saved_biosaddr = pci_read_config(dev, PCIR_BIOS, 4);
+ sc-saved_intline = pci_read_config(dev, PCIR_INTLINE, 1);
+ sc-saved_cachelnsz = pci_read_config(dev, PCIR_CACHELNSZ, 1);
+ sc-saved_lattimer = pci_read_config(dev, PCIR_LATTIMER, 1);
+
+ sc-suspended = 1;
+
+ splx(s);
+
+ return 0;
+ }
+
+ /*
+ * Device resume routine. Restore some PCI settings in case the BIOS
+ * doesn't, re-enable busmastering, and restart the interface if
+ * appropriate.
+ */
+ static int
+ fxp_resume(device_t dev)
+ {
+ struct fxp_softc *sc = device_get_softc(dev);
+ struct ifnet *ifp = sc-sc_if;
+ u_int16_t pci_command;
+ int i, s;
+
+ s = splimp();
+
+ /* better way to do this? */
+ for (i=0; i5; i++)
+ pci_write_config(dev, PCIR_MAPS + i*4, sc-saved_maps[i], 4);
+ pci_write_config(dev, PCIR_BIOS, sc-saved_biosaddr, 4);
+ pci_write_config(dev, PCIR_INTLINE, sc-saved_intline, 1);
+ pci_write_config(dev, PCIR_CACHELNSZ, sc-saved_cachelnsz, 1);
+ pci_write_config(dev, PCIR_LATTIMER, sc-saved_lattimer, 1);
+
+ /* reenable busmastering */
+ pci_command = pci_read_config(dev, PCIR_COMMAND, 2);
+ pci_command |= (PCIM_CMD_MEMEN|PCIM_CMD_BUSMASTEREN);
+ pci_write_config(dev, PCIR_COMMAND, pci_command, 2);
+
+ CSR_WRITE_4(sc, FXP_CSR_PORT, FXP_PORT_SELECTIVE_RESET);
+ DELAY(10);
+
+ /* reinitialize interface if necessary */
+ if (ifp-if_flags IFF_UP)
+ fxp_init(sc);
+
+ sc-suspended = 0;
+
+ splx(s);
+
+ return 0;
+ }
+
static device_method_t fxp_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, fxp_probe),
DEVMETHOD(device_attach,fxp_attach),
DEVMETHOD(device_detach,fxp_detach),
DEVMETHOD(device_shutdown,
Re: Debugging -current SMPNG HANG on heavy disk-io
Hi, ... The frames above are what the system went to as the result of your debugger request. I'd also be interested to see the output of the 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and 'ps' (the macro I promised above). (kgdb) icnt 1215544*566*0 0* 0 0 1 0 1555964*0* 0* 0* 0 0* 22636* 11 1 0 0 0 0 0 441031 imen: 6f0b (kgdb) ps pidprocaddruid pri ppid pgrp flag stat comm wchan 37 c7874a00 c96650000 32 636 004086 3 tar piperd c9663f20 36 c7874bc0 c960a0000 32 636 004006 3 tar FFS node c02f4220 35 c7874d80 c96070000 32 635 004006 3 tar inode c1d2fa00 6 c7874f40 c96040000 32 1 6 004086 3 sh wait c7874f40 5 c7875100 c82950000 4 0 0 000204 3 syncer syncer c03236e8 4 c78752c0 c82930000 4 0 0 100204 3 bufdaemonpsleep c03072f0 3 c7875480 c82910000 4 0 0 000204 3 vmdaemon psleep c0317a00 2 c7875640 c828f0000 4 0 0 100204 3 pagedaemon psleep c02f5938 21 c7875800 c78d40000 1*0 0 000204 2 irq8: rtc 20 c78759c0 c78d20000 1*0 0 000204 2 irq0: clk 19 c7875b80 c78b0 7*0 0 000204 6 irq5: pcm0 18 c7875d40 c788e0000 7*0 0 000204 6 irq7: ppc0 17 c7875f00 c788c0000 7*0 0 000204 6 irq12: psm0 16 c78760c0 c788a0000 7*0 0 000204 2 irq1: atkbd0 15 c7876280 c78870000 6*0 0 000204 6 irq6: fdc0 14 c7876440 c78850000 6*0 0 000204 6 irq15: ata1 13 c7876600 c78830000 6*0 0 000204 2 irq14: ata0 12 c78767c0 c78810000 4 0 0 000204 3 random rndslp c0322934 11 c7876980 c787f0000 15*0 0 008204 6 softinterrupt 10 c7876b40 c787d0000 4 0 0 008204 2 idle 1 c7876d00 c787b0000 4 0 1 004284 3 init wait c7876d00 0 c0322960 c03c0 4 0 0 000204 3 swapper sched c0322960 ... handler. At this point, it would be very interesting to see the value of p-p_comm, which is the process name at the end of the ps listing. (kgdb) proc 35 Why are you interested in this process? It was one of the tar's which I grabbed by hand (without your ps macro) ... Whats next to show :-) Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On Sun, 17 Sep 2000, Alexander Leidinger wrote:
On 17 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
You didn't understand :-). Try the example. It only uses idprio.
rtprio certainly causes system hangs, and the supergiant lock may
increase the problem. Before SMPng, rtprio processes prevented all
non-rtprio processes including important daemons (and I think even
kernel processes) from running. Starting an infinite loop at rtprio
while remotely logged in was fatal because a ^C (character, not signal)
to kill the process couldn't be delivered.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
In message [EMAIL PROTECTED], Bruce Ev ans writes: Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents other user processes from running like a system process might do: idprio 31 sh -c "while :; do :; done" System processes actually hang the entire system until they complete: Are you mixing idprio with rtprio or did I not understand what you explain? You didn't understand :-). Try the example. It only uses idprio. rtprio certainly causes system hangs, and the supergiant lock may increase the problem. Before SMPng, rtprio processes prevented all non-rtprio processes including important daemons (and I think even kernel processes) from running. Starting an infinite loop at rtprio while remotely logged in was fatal because a ^C (character, not signal) to kill the process couldn't be delivered. I can confirm this one, ntpd has for a long time pointlessly raised it's priority to the absolute maximum, and if during debugging it went into a spin it would freeze the system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aic7xxx breaks kernel build
"SK" == Steve Kargl [EMAIL PROTECTED] writes: SK I get the following with sources cvsup'd for cvsup5.freebsd.org SK at 10:00 pm PST on 16 Sep 00. SK make: cannot open /usr/src/sys/dev/aic7xxx/Makefile. Yes, me too. It seems that the file have removed after last commit on aic7xxx drivers... -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [EMAIL PROTECTED] [EMAIL PROTECTED] KFUG http://www.kr.FreeBSD.org Web Data Bank http://www.wdb.co.kr FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
Jordan Hubbard wrote: in summary: PR kern/18756 contains a patch (against -stable, alas, This PR has been explicitly assigned to David Greenman and should be handled by him. As I pointed out in another message, nobody but he is likely to touch the fxp driver under any circumstances so it basically comes down to either him or nobody. So I suspect that either blackmail or bribery is now in order. :-) (Hey, it worked for me with Cameron and the SBLive driver!) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://store.exit.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On 18 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
You didn't understand :-). Try the example. It only uses idprio.
I have dnetc still running with idprio 31 and it didn't hang the entire
system (I'm able to write this mail and compiling a port in the
background while dnetc is running).
As I understand this:
- The man-page of idprio says it allows processes only to run if the
system is idle.
- You say, in my case (dnetc is a cpu hog, isn't it?) idprio prevents
other processes from running (the opposide of what I want).
- I say, dnetc is running in the background with idprio 31 and I'm able
to do usefull work while it is running.
Confused,
Alexander.
--
Reboot America.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On Sun, 17 Sep 2000, Alexander Leidinger wrote:
On 18 Sep, Bruce Evans wrote:
dnetc runns with idprio 31, system cvsupped around Sep 16, 11 CEST from
a german mirror (it contains the idle fixes: src/sys/kern/kern_idle.c,v
1.4), complete build{world,kernel}.
---snip---
last pid: 1666; load averages: 1.10, 1.11, 1.03up 0+00:51:21 16:54:14
Perhaps it really is a system process :-[. idprio on a pure cpu hog prevents
other user processes from running like a system process might do:
idprio 31 sh -c "while :; do :; done"
System processes actually hang the entire system until they complete:
Are you mixing idprio with rtprio or did I not understand what you
explain?
You didn't understand :-). Try the example. It only uses idprio.
I have dnetc still running with idprio 31 and it didn't hang the entire
system (I'm able to write this mail and compiling a port in the
background while dnetc is running).
dnetc presumably blocks occasionally, giving other processes a chance to
run.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
Hi, if the order of the ps macro is correct, here the backtraces of the procs 35,36,37: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Sep 16 19:32:53 CEST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/nihil Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 266615847 Hz CPU: Pentium II/Pentium II Xeon/Celeron (266.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 268369920 (262080K bytes) config #flags wdc0 0xa0ffa0ff Invalid command or syntax. Type `?' for help. config #flags wdc1 0xa0ffa0ff Invalid command or syntax. Type `?' for help. config #iosiz npx0 196608 Invalid command or syntax. Type `?' for help. config #irq pcic0 11 Invalid command or syntax. Type `?' for help. config quit avail memory = 257589248 (251552K bytes) Preloaded elf kernel "kernel.ko" at 0xc03ad000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03ad0ac. Preloaded elf module "linux.ko" at 0xc03ad0fc. Preloaded elf module "linprocfs.ko" at 0xc03ad19c. Pentium Pro MTRR support enabled VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc031ee42 (122) VESA: MagicGraph 256 AV 44K PRELIMINARY npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX host to PCI bridge (AGP disabled) on motherboard pci0: PCI bus on pcib0 pci0: NeoMagic MagicMedia 256AV SVGA controller at 4.0 irq 11 isab0: Intel 82371AB PCI to ISA bridge at device 5.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfe60-0xfe6f at device 5.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 5.2 irq 11 pci0: Intel 82371AB Power management controller at 5.3 pci0: Toshiba Fast Infra Red controller at 9.0 irq 11 pcic-pci0: Toshiba ToPIC97 PCI-CardBus Bridge at device 11.0 on pci0 pcic-pci1: Toshiba ToPIC97 PCI-CardBus Bridge at device 11.1 on pci0 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: Parallel port at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 pps0: Pulse per second Timing Interface on ppbus0 pcic0: Intel i82365 at port 0x3e0-0x3e1 on isa0 pcic0: Polling mode pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0e03 can't assign resources pcm0: Yamaha OPL-SAx at port 0x220-0x233,0x530-0x537,0x388-0x38f,0x330-0x333,0x538-0x539 irq 5 drq 1,0 on isa0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default IPsec: Initialized Security Association Processing. ad0: 24207MB IBM-DARA-225000 [49184/16/63] at ata0-master using UDMA33 ad1: 6194MB IBM-DADA-26480 [13424/15/63] at ata1-master using UDMA33 Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 panic: from debugger syncing disks... done Uptime: 3h22m40s dumping to dev #ad/0x20001, offset 2547840 dump ata0: resetting devices .. done 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 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 --- #0 dumpsys () at
Re: SMPNG kernel on UP
Warner Losh wrote:
In message [EMAIL PROTECTED] Garrett Wollman writes:
: On Thu, 14 Sep 2000 13:46:44 -0600, Warner Losh [EMAIL PROTECTED] said:
: Hmmm, they look good to me. Maybe Mark's system doesn't have group
: operator at gid 5. That's one bad thing about the new DEVFS: it
: appears to enshrine things like this in the kernel...
:
: It would only take a small amount of Makefile magic to fix
: this... something like:
:
: PASSWD?= /etc/passwd
: GROUP?= /etc/group
:
: uidgid.h: ${PASSWD} ${GROUP}
: perl -ne 'split(/:/); print ("#define\tUID_", uc($_[0]), "\t", \
:$_[2], "\n");' ${PASSWD} ${.TARGET}
: perl -ne 'split(/:/); print ("#define\tGID_", uc($_[0]), "\t", \
:$_[2], "\n");' ${GROUP} ${.TARGET}
:
: ...add this to bsd.kmod.mk and include "uidgid.h" as necessary in
: source files.
Hmmm, I like it... But it does suffer from one problem that we
already have enough of in our tree. The build on one system, install
on another problem. It would be better than the current situtation.
Add ${DESTDIR} to PASSWD and GROUP? That will help.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
[EMAIL PROTECTED] http://softweyr.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 100% system time? (SMPng on UP system)
On 18 Sep, Bruce Evans wrote: dnetc presumably blocks occasionally, giving other processes a chance to run. I've started dnetc without idprio (with build in "nice"), it also displays 100% system. And with a closer look (stopped dnetc): 0% user, 0% nice... ? ---snip--- last pid: 36437; load averages: 0.68, 1.44, 1.41up 0+06:53:18 17:23:03 73 processes: 1 running, 70 sleeping, 1 stopped, 1 zombie CPU states: 0.0% user, 0.0% nice, 30.2% system, 5.2% interrupt, 64.6% idle Mem: 63M Active, 13M Inact, 33M Wired, 5644K Cache, 22M Buf, 6580K Free Swap: 266M Total, 43M Used, 223M Free, 15% Inuse, 8K In kill PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 35709 netchild 2 0 10956K 6736K poll 1:48 8.94% 8.94% xmms 732 netchild 2 0 3224K 1048K select 0:05 5.81% 5.81% xterm 658 root 2 0 80016K 33516K select 10:48 4.98% 4.98% XF86_SVGA 457 netchild -6 0 2856K 512K pcmwr0:46 2.49% 2.49% esd ---snip--- Bye, Alexander. -- I believe the technical term is "Oops!" http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$B3d$j$-$C$?$*IU$-9g$$$7$^$;$s$+!)(B
$B$3$NpJs$,ITI,MW$JJ}$O:o=|$J$5$C$F2$5$$!#(B $B$^$?!"K|$,0l=w@-$NJ}$KFO$$$?l9g$b?=$7$o$1$"$j$^$;$s$,:o=|$J$5$C$F2$5$$!#(B == $B(BDi$B$M$C$H$O!%!%!%(B $B!!I^7,R!!=54V!V#S#P#A!*!W!J#2#0#0#0G/#57n#3#1F|9f!K$K$FR2p$5$l$^$7$?!#(B $B!!E4?MR!!!VJ?@.$NN";E;v;UNsEA!W!JH/GdCf!K$K$F$bR2p$5$l$F$$$^$9!*(B == $B3'$5$s$h$/7G(HD$J$I$rMxMQ$7$F3d$j@Z$C$?8r:]4uK=w@-$rJg=8$5$l$F$$$^$9$,!"(B $B@.2L$N$[$I$O$$$+$,$G$7$g$$+!)(B $B!V%;%C%/%9%U%l%s%I$,$G$-$?!W!"$H$$$J}$b$$$i$C$7$c$k$h$$G$9$,!";d$I$b$N(B $B%j%5!%A$K$h$k$H!"#3#0#0?M$K#1?M$$$k$+$$$J$$$+$0$i$$$G$7$+$J$$$h$$G$9!#(B $B$=$NB$NJ}!9$O$4B8$8$N$H$*$j!"7G(!"%a!%kBT$A!"%a!%kAwIU!"7G(!"(B $B%a!%kBT$A!"%a!%kAwIU$NF2!9=d$j$N$h$$G$9!#(B $B!!$J$$@$+$o$+$j$^$9$+!)(B $B!!(B $BEz$($O4JC1$G$9!##1BP#1$G%3%_%e%K%1!%7%g%s$rh$l$P$N$G$9$,!"(B $B$3$l$,0lHVFq$7$$$N$G$9!#(B $B!V(BDi$B$M$C$H!W$G$O!"3'$5$s$K=w@-$r%2%C%H$9$k%N%%O%$rR2p$7$F$$$^$9!#(B $B%M%C%H%J%s%QI,!K!$,$"$l$P#1BP#1$N%3%_%e%K%1!%7%g%s$OEv$?$jA0$K$J$j$^$9!#(B $B!V(BDi$B$M$C$H!W$N%M%C%H%J%s%QI,!K!$G%M%C%H%J%s%Q;U$,$$/$$/CB@8Cf$G$9!#(B $B9XF~T$NBN83CL$J$I$O!"L5NA$G9XFI$G$-$k!V%M%C%H%J%s%Q$^$,$8$s!W$K$F(B $B9%I7G:\Cf$G$9!*(B $B$^$?!"%M%C%H%J%s%Q$NBe9T6HL3$b9T$C$F$$$^$9!#(B $B!!(B $B!!#2G/$G#5#0?M0Je$r?)$C$?%M%C%H%J%s%Q;U$H$7$F!"(B $B!!!V#S#P#A!*#2#0#0#0G/#5!?#3#1F|9f!W(B $B!!E4?MR!VN"%b%N(BJAPAN$B!WJL:}$N!VJ?@.$NN";E;v;UNsEA!W(B $B!!$K$FR2p$5$l$^$7$?!#(B $B!V(BDi$B$M$C$H!W$G$O!"%N%%O%9XF~$*$h$S!"%J%s%QBe9T$ru$1$?CK@-2q0wMM(B $B$N$_L5NA$N=54V3d$j@Z$j%^%,%8%s$rH/9TCf$G$9!JG/4V9XFINA#6@i1_!K!#(B $BFbMF$O!"3'$5$s$,=w@-$rR2p$7$F$b$i$C$?$"$H!"(B $B$I$$9$l$P=w@-$,+J,@lMQ$N0?M$K$J$k$+!"$H$+!"(B $B$J$+$J$+O"Mm$,Mh$J$$=w@-$r4JC1$K?6$j8~$+$;$kJ}K!$J$I!"(B $B;d$NBN83$r$^$8$($FR2p$7$^$9!#(B $B$3$N%a!%k%^%,%8%s$OHs2q0wMM$OM-NA$H$J$j$^$9!#(B $B%J%s%QI,!K!$N9XF~$*$h$S%J%s%QBe9T$ru$1$?3'$5$s$O(B $Bu$1$?7n$+$i#1G/4V$OL5NA$G$9$N$G!"$*3Z$7$_$K$*BT$A2$5$$!#(B $B!!\$7$/$O!V(BDi$B$M$C$H!W$N%[!%`%Z!%8$^$G$*1[$72$5$$!#(B $B!!LLGr$$$h$$K=w@-$,$R$C$+$+$kJ}K!$rEAx$7$^$9$h!#(B == $B""2qRL!'(B $B!V(B Di$B$M$C$H!W(B $B""(BWEB $B!!!'!!(Bhttp://www5a.biglobe.ne.jp/~di-net/index4.htm == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Please review: small change in sys/i386/isa/clock.c and sys/alpha/alpha/clock.c for PC-Card melody beep code.
Hi.
FreeBSD developers.
I have a plan to commit PC-Card melody beep code into
5-current(/sys/pccard/pccard_beep.c) from PAO3. But it needs to
call sysbeepstop@sys/${ARCH}/${BUS}/clock.c function from
pccard_beep.c.
May I commit below small changes to sys/i386/isa/clock.c and
sys/alpha/alpha/clock.c?
MAIN POINT:
static void sysbeepstop -- void sysbeepstop.
Full PC-Card melody patch is in below URL.
http://people.FreeBSD.org/~sanpei/5-current/sys-pccard-pccard_beep_melody-2917.diff
---
MIHIRA, Sanpei Yoshiro
Yokohama, Japan.
--- sys/i386/isa/clock.c.orgTue May 9 10:16:31 2000
+++ sys/i386/isa/clock.cSat May 6 00:50:11 2000
@@ -510,7 +510,7 @@
#endif
}
-static void
+void
sysbeepstop(void *chan)
{
outb(IO_PPI, inb(IO_PPI)0xFC); /* disable counter2 output to speaker */
--- sys/alpha/alpha/clock.c.org Fri Sep 15 18:05:23 2000
+++ sys/alpha/alpha/clock.c Fri Sep 15 18:05:52 2000
@@ -626,7 +626,7 @@
return (0);
}
-static void
+void
sysbeepstop(void *chan)
{
outb(IO_PPI, inb(IO_PPI)0xFC); /* disable counter2 output to speaker */
--- sys/i386/include/clock.h.orgFri Sep 15 18:07:58 2000
+++ sys/i386/include/clock.hFri Sep 15 18:09:19 2000
@@ -44,6 +44,7 @@
intrelease_timer1 __P((void));
#endif
intsysbeep __P((int pitch, int period));
+void sysbeepstop __P((void *chan));
void i8254_restore __P((void));
#endif /* _KERNEL */
--- sys/alpha/include/clock.h.org Mon Sep 18 00:38:54 2000
+++ sys/alpha/include/clock.h Mon Sep 18 00:39:12 2000
@@ -17,6 +17,7 @@
void DELAY __P((int usec));
intsysbeep __P((int pitch, int period));
+void sysbeepstop __P((void *chan));
intacquire_timer2 __P((int mode));
intrelease_timer2 __P((void));
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fxp suspend/resume hangs
On Sun, Sep 17, 2000 at 05:31:45AM -0700, David Greenman wrote: in summary: PR kern/18756 contains a patch (against -stable, alas, sorry) which fixes kernel hangs in the fxp driver on some laptops after a resume from suspend. while quite a few people appear to be using this patch successfully, it hasn't been committed -- david greenman had an entirely reasonable objection to one aspect of the patch's behavior. unfortunately, my knowledge of the kernel isn't sufficient to adequately address david's concerns, and though i've mailed him to ask for guidance twice over the past 4 months, i haven't received a response. that's probably my fault, i probably should have been mailing -current to being with. I can only find the 5/22 email regarding this, so I seem to have missed your second message. With over a thousand emails a day coming into my inbox, this shouldn't be too surprising. My response to the 5/22 message was this: ... This could be a problem. If an interrupt occurs, it must be acknowledged otherwise you'll be stuck in an infinit loop - PCI interrupts are level sensitive and must be cleared in the ISR. ... In short, while it may fix a hang in your laptop case, it opens the driver up to a hang if an unexpected interrupt occurs while IFF_RUNNING is clear. I think this is dangerous enough that I don't think the code should not be compiled as part of the standard driver. One just cannot ignore level- sensitive PCI interrupts. While programming for cardbus under FreeBSD, I ran into similar issues that when cards were powere down or removed where they would go into an infinite loop reading status registers. What actually happens is the register returns 0x whenever it is read, and the resolution I used was to check whether it is equal to 0x and do appropiate measures when it is found to be true. It looks from reading the PR that this might be a similar issue here -- that the card is powered down during suspend and of wakeup the reads to FXP_CSR_SCB_STATACK and cbp-cb_status returns 0xff. I believe this issue can be resolved by checking whether what was read equals 0x and abort the loop. This should be fairly safe as interrups shouldn't happen during powerdown (and can't be ack'ed anyway)... -- (o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o) \\\_\Jonathan Chen [EMAIL PROTECTED] /_/// ) No electrons were harmed during production of this message ( ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please review: small change in sys/i386/isa/clock.c and sys/alpha/alpha/clock.c for PC-Card melody beep code.
I've seen these patches many times and think that it is a good idea. This interface needs to be exported so that the pccard system sounds don't interfere with normal systme sounds. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
How much sense does it make to think about implementing tee and
select methods this way? Like "open file1 and file2 and write to
both of them whatever I give to you" and "give me data coming in
from whatever file is in this set"? The only problem is to
determine available characters to separate these names. '+' as
well as ':', ',' and ';' are perfectly valid characters for
constructing filenames. '' seems to be too, but could be used
rarely enough. And the split upon these new separators actually
should be done only when the appropriate SDO_ flags are passed.
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
[snip]
parameters) have to pass certain checks. Nobody should try to
read from "|command". And I cannot see any use for "write to
whatever descriptor is ready to write to first" as would result
from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That feature
should be in there too :)
I do see a use to "write to whatever descriptor is ready first". It
could be used for a very simple multithreading-like implementation.
Spawn 8 child processes, attach them to one stream with
superduperopen(), and pass single-byte commands to one that is waiting
to handle one. If all 8 are busy, you block, or return something like
EAGAIN. This description is very pseudo-something, btw :)
Feel free to correct the flag's data type. I have the feeling
not all int's have 32bits. :) Some other means of storage might
int works for open, I doubt whether we need more options than open does :)
be more appropriate while still being easy to combine and to pass
to the function. But I feel strings like "STD,PIPE,TEE" are
There's no reason for that. We have a compiler that can parse *unquoted*
strings like STD | PIPE | TEE and create single int's out of that. Ain't
it wonderful :)
harder to parse and single character notation like the "wt" mode
flags are harder to find (think of) and to read (in terms of
eyeballing the source code) for the sdo case.
I do think the "w+" 'n stuff notation in popen sucks. This is our chance
to turn those into bitflags too, for superduperopen anyway.
Greetz, Peter
--
dataloss networks
'/ignore-ance is bliss' - me
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch for openssh
In article [EMAIL PROTECTED], Alexander Leidinger [EMAIL PROTECTED] wrote: Index: authfd.c === RCS file: /big/FreeBSD-CVS/src/crypto/openssh/authfd.c,v retrieving revision 1.6 diff -u -r1.6 authfd.c --- authfd.c 2000/09/10 09:35:37 1.6 +++ authfd.c 2000/09/16 15:27:25 @@ -178,7 +178,7 @@ if (sock 0) return NULL; - auth = xmalloc(sizeof(*auth)); + auth = xmalloc(sizeof(AuthenticationConnection)); auth-fd = sock; buffer_init(auth-identities); auth-howmany = 0; What is the point of that change? Functionally it makes no difference at all, since "*auth" is an AuthenticationConnection. It makes the code harder to maintain in case the type of "auth" is changed in the future. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fdescfs updates--coming to a devfs near you!
On Thu, 14 Sep 2000, Ben Smithurst wrote:
Poul-Henning Kamp wrote:
I must admit that I think in general that /dev/std{in,out,err} and /dev/fd
is bogus. It looks like something which happened "because we can" more
than something which has a legitimate need.
You think adding a hack to every program to support "-" to mean
stdout/stdin is better? It seems to be that saying "/dev/stdin" when
you mean stdin is better than saying "-" and hoping the application
handles that correctly. Of course many programs will read stdin by
default, and write stdout by default, but that doesn't help when you
want to read more than one file, one of which is stdin.
If anything I would propose we ditch it...
And break loads of scripts at the same time?
I recently ran into revelant problem with /dev/stdout, while
working on some software under linux that expected /dev/stdout as an
argument instead of using stdout.
Using the device file breaks, if the process is suid to a non-root
user. This is because it cannot open /dev/stdout, which is owned by your
UID and not the EUID of the process to which the device was passed. My
solution was to add the "-" hack and use the existing open descriptor.
Still, I don't think /dev/stdout and friends are such bad things
that they should be abandoned. They are present in other OS's and it does
help avoid making named pipes and the such when you need the behavior the
special devices provide. I think it would simple create minor poratability
issues for third party software.
Adrian
--
[ [EMAIL PROTECTED] -- Ubergeeks Consulting -- http://www.ubergeeks.com/ ]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
aic7xxx changes break kernel builds
hotrats:root[211] setenv KERNEL HOTRATS hotrats:root[212] make buildkernel -- Rebuilding kernel(s) -- === HOTRATS mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -r -d /usr/obj/usr/src/sys/HOTRATS HOTRATS Don't forget to do a ``make depend'' Kernel build directory is /usr/obj/usr/src/sys/HOTRATS cd /usr/obj/usr/src/sys/HOTRATS; MAKESRCPATH=/usr/src/sys/dev/aic7xxx make -f /usr/src/sys/dev/aic7xxx/Makefile make: cannot open /usr/src/sys/dev/aic7xxx/Makefile. *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. It has been this way since last night 10pm PST. Anyone have a tip on generating the missing Makefile? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Sunday, 17 September 2000 at 16:29:41 +0200, Michael Reifenberger wrote: Hi, ... The frames above are what the system went to as the result of your debugger request. I'd also be interested to see the output of the 'icnt' macro (if this is UP machine) or 'icnt1' (if it's SMP), and 'ps' (the macro I promised above). (kgdb) icnt 1215544*566*0 0* 0 0 1 0 1555964*0* 0* 0* 0 0* 22636* 11 1 0 0 0 0 0 441031 imen: 6f0b (kgdb) ps pidprocaddruid pri ppid pgrp flag stat comm wchan 37 c7874a00 c96650000 32 636 004086 3 tar piperd c9663f20 36 c7874bc0 c960a0000 32 636 004006 3 tar FFS node c02f4220 35 c7874d80 c96070000 32 635 004006 3 tar inode c1d2fa00 6 c7874f40 c96040000 32 1 6 004086 3 sh wait c7874f40 5 c7875100 c82950000 4 0 0 000204 3 syncer syncer c03236e8 4 c78752c0 c82930000 4 0 0 100204 3 bufdaemonpsleep c03072f0 3 c7875480 c82910000 4 0 0 000204 3 vmdaemon psleep c0317a00 2 c7875640 c828f0000 4 0 0 100204 3 pagedaemon psleep c02f5938 21 c7875800 c78d40000 1*0 0 000204 2 irq8: rtc 20 c78759c0 c78d20000 1*0 0 000204 2 irq0: clk 19 c7875b80 c78b0 7*0 0 000204 6 irq5: pcm0 18 c7875d40 c788e0000 7*0 0 000204 6 irq7: ppc0 17 c7875f00 c788c0000 7*0 0 000204 6 irq12: psm0 16 c78760c0 c788a0000 7*0 0 000204 2 irq1: atkbd0 15 c7876280 c78870000 6*0 0 000204 6 irq6: fdc0 14 c7876440 c78850000 6*0 0 000204 6 irq15: ata1 13 c7876600 c78830000 6*0 0 000204 2 irq14: ata0 12 c78767c0 c78810000 4 0 0 000204 3 random rndslp c0322934 11 c7876980 c787f0000 15*0 0 008204 6 softinterrupt 10 c7876b40 c787d0000 4 0 0 008204 2 idle 1 c7876d00 c787b0000 4 0 1 004284 3 init wait c7876d00 0 c0322960 c03c0 4 0 0 000204 3 swapper sched c0322960 ... handler. At this point, it would be very interesting to see the value of p-p_comm, which is the process name at the end of the ps listing. (kgdb) proc 35 Why are you interested in this process? It was one of the tar's which I grabbed by hand (without your ps macro) ... Whats next to show :-) To quote: At this point, it would be very interesting to see the value of p-p_comm, which is the process name at the end of the ps listing. You could also show the content of p-p_pid. If you don't have a p pointer in the frame you're looking at, use ((struct *proc)gd_curproc)-p_pid and ((struct *proc)gd_curproc)-p_comm. We need to know what is hanging. I'm probably going on holiday for the rest of the week; somebody else should pick this one up. 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: aic7xxx changes break kernel builds
On Sun, 17 Sep 2000, Steve Kargl wrote: hotrats:root[211] setenv KERNEL HOTRATS hotrats:root[212] make buildkernel -- Rebuilding kernel(s) -- === HOTRATS mkdir -p /usr/obj/usr/src/sys cd /usr/src/sys/i386/conf; PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -r -d /usr/obj/usr/src/sys/HOTRATS HOTRATS Don't forget to do a ``make depend'' Kernel build directory is /usr/obj/usr/src/sys/HOTRATS cd /usr/obj/usr/src/sys/HOTRATS; MAKESRCPATH=/usr/src/sys/dev/aic7xxx make -f /usr/src/sys/dev/aic7xxx/Makefile make: cannot open /usr/src/sys/dev/aic7xxx/Makefile. *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. It has been this way since last night 10pm PST. Anyone have a tip on generating the missing Makefile? I hit the same, went into /sys/i386/conf and ran 'config' and built the kernel "the old fashioned way", and it went through perfectly ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Mon, 18 Sep 2000, Greg Lehey wrote: ... You could also show the content of p-p_pid. If you don't have a p pointer in the frame you're looking at, use ((struct *proc)gd_curproc)-p_pid and ((struct *proc)gd_curproc)-p_comm. We need to know what is hanging. Sorry doesn't seem to work: (kgdb) p p-p_comm No symbol "p" in current context. (kgdb) p ((struct*proc)gd_curproc)-p_pid A syntax error in expression, near `proc)gd_curproc)-p_pid'. (kgdb) p ((struct *proc)gd_curproc)-p_comm A syntax error in expression, near `proc)gd_curproc)-p_comm'. (kgdb) p gd_curproc $1 = 0xc78760c0 Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Monday, 18 September 2000 at 1:23:30 +0200, Michael Reifenberger wrote: On Mon, 18 Sep 2000, Greg Lehey wrote: ... You could also show the content of p-p_pid. If you don't have a p pointer in the frame you're looking at, use ((struct *proc)gd_curproc)-p_pid and ((struct *proc)gd_curproc)-p_comm. We need to know what is hanging. Sorry doesn't seem to work: (kgdb) p p-p_comm No symbol "p" in current context. (kgdb) p ((struct*proc)gd_curproc)-p_pid A syntax error in expression, near `proc)gd_curproc)-p_pid'. (kgdb) p ((struct *proc)gd_curproc)-p_comm A syntax error in expression, near `proc)gd_curproc)-p_comm'. (kgdb) p gd_curproc $1 = 0xc78760c0 Oops, that's what comes of typing hurriedly early in the morning. p ((struct proc *)gd_curproc)-p_comm p ((struct proc *)gd_curproc)-p_pid 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: Debugging -current SMPNG HANG on heavy disk-io
On Mon, 18 Sep 2000, Greg Lehey wrote: ... Oops, that's what comes of typing hurriedly early in the morning. p ((struct proc *)gd_curproc)-p_comm p ((struct proc *)gd_curproc)-p_pid Works better: (kgdb) p ((struct proc *)gd_curproc)-p_comm $6 = "irq1: atkbd0\000\000\000\000" (kgdb) p ((struct proc *)gd_curproc)-p_pid $7 = 0x10 Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Debugging -current SMPNG HANG on heavy disk-io
On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote: On Mon, 18 Sep 2000, Greg Lehey wrote: ... Oops, that's what comes of typing hurriedly early in the morning. p ((struct proc *)gd_curproc)-p_comm p ((struct proc *)gd_curproc)-p_pid Works better: (kgdb) p ((struct proc *)gd_curproc)-p_comm $6 = "irq1: atkbd0\000\000\000\000" (kgdb) p ((struct proc *)gd_curproc)-p_pid $7 = 0x10 Hmm. I suppose that's reasonable, since you've just pressed a key. We obviously have a problem here, but I'm not going to be able to look at it myself until Friday or Saturday. Anybody else want to take a look? There's also the possibility that a problem I had seen and not investigated could in fact be the same problem: I got it tarring and untarring across an NFS connection. 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: Debugging -current SMPNG HANG on heavy disk-io
Greg Lehey wrote: On Monday, 18 September 2000 at 1:29:34 +0200, Michael Reifenberger wrote: On Mon, 18 Sep 2000, Greg Lehey wrote: ... Oops, that's what comes of typing hurriedly early in the morning. p ((struct proc *)gd_curproc)-p_comm p ((struct proc *)gd_curproc)-p_pid Works better: (kgdb) p ((struct proc *)gd_curproc)-p_comm $6 = "irq1: atkbd0\000\000\000\000" (kgdb) p ((struct proc *)gd_curproc)-p_pid $7 = 0x10 Hmm. I suppose that's reasonable, since you've just pressed a key. We obviously have a problem here, but I'm not going to be able to look at it myself until Friday or Saturday. Anybody else want to take a look? There's also the possibility that a problem I had seen and not investigated could in fact be the same problem: I got it tarring and untarring across an NFS connection. Hmm, could it be lockmgr() related? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh and scp fail connecting to a root account
On Fri, Sep 15, 2000 at 03:40:12PM +0100, Konstantin Chuguev wrote: Udo Schweigert wrote: after a fresh build of -current openssh does not work if connecting to the root-user. For example (tested from a -stable machine, but the same from 4.1-RELEASE): Yes, I've been seeing the same thing since the checkout of the SMPng stuff... No idea why it's happening. I've seen similar things intermittently over the past 10 days, and specifically the same problem for the past three days or so. I'm pretty sure that the problems have been associated with the random device rather than the SMP work specifically. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh and scp fail connecting to a root account
On 17 Sep 2000, Jason Evans wrote: On Fri, Sep 15, 2000 at 03:40:12PM +0100, Konstantin Chuguev wrote: Udo Schweigert wrote: after a fresh build of -current openssh does not work if connecting to the root-user. For example (tested from a -stable machine, but the same from 4.1-RELEASE): Yes, I've been seeing the same thing since the checkout of the SMPng stuff... No idea why it's happening. I've seen similar things intermittently over the past 10 days, and specifically the same problem for the past three days or so. I'm pretty sure that the problems have been associated with the random device rather than the SMP work specifically. Well, the crash is apparently due to malloc flags - remove the /etc/malloc.conf link and it may work better. I've only seen this once, and when I tried to run sshd under gdb it went away, and now I can't reproduce it again. :-( Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
On Sun, Sep 17, 2000 at 20:36 +0200, Peter van Dijk wrote:
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
[ ... how to find separating chars not used in filenames ... ]
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
Of course it would be the cleanest thing to do, and I was aware
of this possibility. But that's when the interface is _very_
much different from fopen(3). That's where I'm reluctant to
introduce this hard a change. :) In addition it was not quite
clear how appropriate this semantics would be, at all.
Unless one sees this (yet to be renamed accordingly:) function as
something very different from fopen and "easy adaption of
existing utilities" is not so much of a concern, I still hesitate
to put this much more burdon on the programmer: opening single
files like fopen(3) did before would now mean to handle a "list
of one filenames" instead of passing whatever was there before --
just to have the lib handle stdin recognition.
I could suggest something even more ugly than the above "xy" for
those who want easy adaption:
superduperopen(char *fn, char *mode, int flags, ...);
with the \dots being zero or more filenames, only evaluated when
the flags suggest to do so. But it tears the first and any other
filename apart. The other solution was to provide two functions:
one fopen like plus the flags for when only one filename is
needed and another with a filename list, mode, and flags; being
the first a wrapper for the second (much as IPC::Open2 and
IPC::Open3 are). This would allow for a simple fixsized two
element array handled in the wrapper without the app's need to
care about anything more but the SDO_ flags for STD in the
existing cases we mainly talk about (cat(1) and the like).
After all I'm still not sure how useful this kind of extension
would be. It all started out with the wish for knowing "-" and
"|cmd" / "cmd|" where an interface like
superduperopen(char *fn, char *mode, int flags);
is sufficient.
[snip]
parameters) have to pass certain checks. Nobody should try
to read from "|command". And I cannot see any use for "write
to whatever descriptor is ready to write to first" as would
result from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That
feature should be in there too :)
That's obvious (isn't it?). But there are definitely
combinations which aren't really useful. And some even shouldn't
be allowed at all.
Which brings me to a completely different topic: How much sense
does it make being able to read(2) directories? Shouldn't be
other functions (like stat, chdir, opendir friends) sufficient
and shouldn't read fail with EISDIR or something similar? I've
been bitten quite often from the garbled output of "head *" with
damaged terminal fonts afterwards. I know Linux had this before
but has been fixed for several years now. I'm aware this could
be a religious topic, but I feel it should have been discussed
before. It's just that I think searching for "read" or
"directory" in the list's archive is not very useful. Where can
I find more information on the reasons to still allow for this
misfeature (it's how I judge this short of knowing any
advantages).
I do see a use to "write to whatever descriptor is ready
first". It could be used for a very simple multithreading-like
implementation. Spawn 8 child processes, attach them to one
stream with superduperopen(), and pass single-byte commands to
one that is waiting to handle one.
Yes, but the same restriction as to "read from whatever is ready
first" apply: The type of data has to be "fixed size and without
problems splittable" or "not really produced in parallel but more
alternatively" as one byte commands are or keystrokes could be.
That's where I see only limited use for these. It heavily
depends on the applications' environments.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: superduperopen(3) (was: Fdescfs updates--coming to a devfs near you!)
I think this thread needs to be killed. Whipping a horse that was dead 3
days ago is way too much. People have expressed thier opposition to PHK's
post and so it should end there.
For the love of cgi scripts, please keep /dev/stdin out so that peoples
web work can be sent to from the masses.
This is posted on NetBSD's web page, "Solutions and not hacks"
Stop trying to hack up a broken idea in order to kinda-sorta make it work
and produce a "Solution"
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Gerhard Sittig
Sent: Sunday, September 17, 2000 3:18 PM
To: [EMAIL PROTECTED]
Subject: Re: superduperopen(3) (was: Fdescfs updates--coming to a devfs
near you!)
On Sun, Sep 17, 2000 at 20:36 +0200, Peter van Dijk wrote:
On Sat, Sep 16, 2000 at 10:04:47AM +0200, Gerhard Sittig wrote:
crazy mode on
[ ... how to find separating chars not used in filenames ... ]
e.g.
superduperopen("file1file2", "a+", SDO_TEEFILES)
superduperopen("file1file2", "r" , SDO_SELECT)
FILE *superduperopen(char *files[], char *type, int flags);
Of course it would be the cleanest thing to do, and I was aware
of this possibility. But that's when the interface is _very_
much different from fopen(3). That's where I'm reluctant to
introduce this hard a change. :) In addition it was not quite
clear how appropriate this semantics would be, at all.
Unless one sees this (yet to be renamed accordingly:) function as
something very different from fopen and "easy adaption of
existing utilities" is not so much of a concern, I still hesitate
to put this much more burdon on the programmer: opening single
files like fopen(3) did before would now mean to handle a "list
of one filenames" instead of passing whatever was there before --
just to have the lib handle stdin recognition.
I could suggest something even more ugly than the above "xy" for
those who want easy adaption:
superduperopen(char *fn, char *mode, int flags, ...);
with the \dots being zero or more filenames, only evaluated when
the flags suggest to do so. But it tears the first and any other
filename apart. The other solution was to provide two functions:
one fopen like plus the flags for when only one filename is
needed and another with a filename list, mode, and flags; being
the first a wrapper for the second (much as IPC::Open2 and
IPC::Open3 are). This would allow for a simple fixsized two
element array handled in the wrapper without the app's need to
care about anything more but the SDO_ flags for STD in the
existing cases we mainly talk about (cat(1) and the like).
After all I'm still not sure how useful this kind of extension
would be. It all started out with the wish for knowing "-" and
"|cmd" / "cmd|" where an interface like
superduperopen(char *fn, char *mode, int flags);
is sufficient.
[snip]
parameters) have to pass certain checks. Nobody should try
to read from "|command". And I cannot see any use for "write
to whatever descriptor is ready to write to first" as would
result from "w" and SDO_SELECT.
But they should be able to read from "command|", ofcourse. That
feature should be in there too :)
That's obvious (isn't it?). But there are definitely
combinations which aren't really useful. And some even shouldn't
be allowed at all.
Which brings me to a completely different topic: How much sense
does it make being able to read(2) directories? Shouldn't be
other functions (like stat, chdir, opendir friends) sufficient
and shouldn't read fail with EISDIR or something similar? I've
been bitten quite often from the garbled output of "head *" with
damaged terminal fonts afterwards. I know Linux had this before
but has been fixed for several years now. I'm aware this could
be a religious topic, but I feel it should have been discussed
before. It's just that I think searching for "read" or
"directory" in the list's archive is not very useful. Where can
I find more information on the reasons to still allow for this
misfeature (it's how I judge this short of knowing any
advantages).
I do see a use to "write to whatever descriptor is ready
first". It could be used for a very simple multithreading-like
implementation. Spawn 8 child processes, attach them to one
stream with superduperopen(), and pass single-byte commands to
one that is waiting to handle one.
Yes, but the same restriction as to "read from whatever is ready
first" apply: The type of data has to be "fixed size and without
problems splittable" or "not really produced in parallel but more
alternatively" as one byte commands are or keystrokes could be.
That's where I see only limited use for these. It heavily
depends on the applications' environments.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To
Can't build a kernel
If I use the buildkernel target I get the following: make: cannot open /usr/amd/realmounts/slave/usr/current/src/sys/dev/aic7xxx/Makefile. *** Error code 2 Stop in /usr/amd/realmounts/slave/usr/current/src. *** Error code 1 If I use the old way, I get errors about a pointer with an incomplete type in aac (whatever that is). Doug -- "The dead cannot be seduced." - Kai, "Lexx" Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
