Re: can't sshd into box
Andre Guibert de Bruet wrote: > On Mon, 3 Mar 2003, Wayne Barnes wrote: > > Immediately after rebooting, I get this: > > > > [EMAIL PROTECTED]:/home/wayne>telnetd -debug > > telnetd: bind: Address already in use > > > > This doesn't happen on my other (working) system. > > Could this be a clue to my problem? > > Telnetd is telling you that something else is listening on port 23. This > is most probably inetd. Do a 'killall inetd' then try that command. That's not only going to stop inetd from sitting on the port, it will probably also make telnet into the box start working, if it's related to the TCP wrappers (if he had modified his hosts.allow with the advice from a previous poster, he would not be having this problem, if that happens, so rather than posting his problem over and over again, maybe he should read the responses, and at least tell us if they worked?). Otherwise, another common culprit is ipfw; if he has the firewall enabled, the default is to block everything. Given that he got a connection, and that it was subsequently closed, though, rather than not getting a connection at all, it's a safe bet that it's the TCP wrappers, not the ipfw, that is causing the trouble. In which case, he should take the advice on the hosts.allow file contents that he was given earlier, and it will fix his problem... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't sshd into box
On Mon, 3 Mar 2003, Wayne Barnes wrote: > Immediately after rebooting, I get this: > > [EMAIL PROTECTED]:/home/wayne>telnetd -debug > telnetd: bind: Address already in use > > This doesn't happen on my other (working) system. > Could this be a clue to my problem? Wayne, Telnetd is telling you that something else is listening on port 23. This is most probably inetd. Do a 'killall inetd' then try that command. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
can't sshd into box
Dear FreeBSD, Immediately after rebooting, I get this: [EMAIL PROTECTED]:/home/wayne>telnetd -debug telnetd: bind: Address already in use This doesn't happen on my other (working) system. Could this be a clue to my problem? -- -- Wayne M Barnes, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
can't sshd into box
Dear Jason, [Not too many people jumping onto this thread to help me.] The first two non-bold lines on rebooting, are: hw.bus.devctl_disable: 0 -> 1 Entropy harvesting: interrupts ethernet point_to_point. So I try: [EMAIL PROTECTED]:/home/wayne>sysctl hw.bus.devctl_disable: 1 -> 0 [but the result is:] sysctl: unknown oid 'hw.bus.devctl_disable:' So what the heck is "Entropy harvesting" ? Could this be blocking my incoming contact attempts? -- Wayne M Barnes [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
Tinderbox FAQ: http://people.FreeBSD.org/~mike/tinderbox.html -- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >>> /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Mon Mar 3 00:15:48 EST 2003 -- ===> hme make: don't know how to make bsd.README. Stop *** Error code 2 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
`npx_driver',`npx_devclass' defined but not used
Ladies and Gentlemen From a fresh cvsup of RELENG_5_0 this afternoon, make buildkernel returns: cc1: warnings being treated as errors /usr/src/sys/i386/isa/npx.c:1078: warning: `npx_driver' defined but not used /usr/src/sys/i386/isa/npx.c:1084: warning: `npx_devclass' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/BINKY1. *** Error code 1 Stop in /usr/src. *** Error code 1 This is with -march=pentium-mmx in make.conf and device npx in my kernel configuration. Suggestions? Remedies? Thankyou. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
On Sunday 02 March 2003 18:08, Jens Rehsack wrote: > Now, that OpenWatcom is released, the FreeBSd port of it should follow. > And maybe someone will try to compile the kernel and world with it. If > that would work, this would be great, because the watcom compiler > generates much better code than gcc does, even than gcc -O3 (and all > known optimizations on). Is someone working on such a port? Will a "bootstrap" port to build it with GCC be part of the work? -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Please test: cluster locking patch.
I have a patch that should clear up buf locking issues and race conditions in vfs_cluster.c. Since this code is so tricky I'd like to have a few people test it. You should notice no difference in your system performance or behavior. Please see: http://www.chesapeake.net/~jroberson/cluster.diff I will post on arch about the contents of the patch. Cheers, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wireless Networking
On Mon, Mar 03, 2003 at 01:07:28AM +, Suneel Jhangiani wrote: > I finally managed to get my hands on a couple of other Wireless network > cards (previously I had a DWL-650+ based on the unsupported TI chipset). > > I have tried both cards to no avail on FreeBSD v4.7 and was wondering if > anyone has either working under Current? > > The two cards are: > > 3Com OfficeConnect PC Card (3CRSHPW_96 Wireless LAN PC Card) > Intel PRO/Wireless 2011B LAN PC Card > > Regards, > > Suneel. > I think the 3com one has an Atmel chipset, which is unsupported. Don't about the other one. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Wireless Networking
I finally managed to get my hands on a couple of other Wireless network cards (previously I had a DWL-650+ based on the unsupported TI chipset). I have tried both cards to no avail on FreeBSD v4.7 and was wondering if anyone has either working under Current? The two cards are: 3Com OfficeConnect PC Card (3CRSHPW_96 Wireless LAN PC Card) Intel PRO/Wireless 2011B LAN PC Card Regards, Suneel. ** A disclaimer applies to all email sent from Inter-Computer Technology Limited. For the full text, see http://home.inctech.com/Content/Legal/EmailDisclaimer.htm ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: Driver mega-commit ahead.
In message: <[EMAIL PROTECTED]> "Poul-Henning Kamp" <[EMAIL PROTECTED]> writes: : This particular sweep gives os much better cross-branch source : portability and therefore I think it is exactly the kind of thing : we want before the RELENG_5 branch. I for one plan on MFC'ing the "NULL->nofoo" stuff so I can move my drivers to it and then MFC w/o hassle. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: eUSB Multimediacard flash storage
Sorry, I know it is poor form to reply to myself. I tried to do a "camcontrol reset all" while it was giving me this error. Nothing appeared to happen (the error continued to scroll) so I removed the USB device. (probe0:umass-sim0:0:0:0): Retrying Command (probe0:umass-sim0:0:0:0): CAM Status 0x39 umass-sim0:0:0:0: func_coe 0x0901: Invalid target (target needed) (probe0:umass-sim0:0:0:0): Retrying Command (probe0:umass-sim0:0:0:0): CAM Status 0x39 umass-sim0:0:0:0: func_code 0x0901: Invalid target (target needed) (probe0:umass-sim0:0:0:0): Retrying Command (probe0:umass-sim0:0:0:0): Error 5 (probe0:umass-sim0:0:0:0): Retries Exhausted umass-sim0:0:0:0: func_code 0x0901: Invalid target (target needed) (da0:umass-si,0:0:0:0): Synchronize cahce failed, status == 0x39, scsi status == 0x0 umass-sim0:0:0:0: func_code 0x0901: Invalid target (target needed) (da0:umass-sim0:0:0:0): removing device entry su-2.05b# panic (null): Unknown state 1 syncing disks, buffers remaining panic: bwrite: buffer is not busy??? Here is another panic from a kernel built Feb 4. The computer was booted with the USB device attached, and it refused to proceed past "da0: 15mb (31424 512 byte sectors.." so I detached it. umass0: SCM Microsystems Inc. eUSB MultiMediaCard Adapter, rev 1.10/4.04, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 15MB (31424 512 byte sectors: 64H 32S/T 15C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached umass0: SCM Microsystems Inc. eUSB MultiMediaCard Adapter, rev 1.10/4.04, addr 2 umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR (da0:umass-sim0:0:0:0): removing device entry Opened disk da0 -> 5 umass0: at uhub0 port 1 (addr 2) disconnected umass0: detached umass0: SCM Microsystems Inc. eUSB MultiMediaCard Adapter, rev 1.10/4.04, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 15MB (31424 512 byte sectors: 64H 32S/T 15C) Fatal trap 12: page fault while in kernel mode fault virtual addresstion pointer= 0x8:0xc02faac0 stack pointer= 0x10:0xd67b0b74 frame pointer= 0xse 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupnumber= 12 panic: page fault If more information is needed on either of the panics, please inform me. Thank you, Pat Lathem Pat Lathem wrote: Hi list, I'm still trying to get this drive working. I booted with a -v flag, and this the output now: Can anyone recommend any changes or patches to get this to work work? My kernel is 5.0-currrent built on March 1st. Thank you, Pat Lathem To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: FreeBSD Bluetooth stuff
Hi Max, > 1) compile and install hcidump from the snapshot's ports/ directory Recompiled and reinstalled. All went fine. > 2) make sure you have clean setup, i.e. >- run # rc.bluetooth stop >- disconnect the device from the PC >- reset mouse >- connect device back to PC >- run # rc.bluetooth start >- in separate window run # hcidump -x >- run # hccontrol -n hci inquiry >- run # sdptool browse I followed this sequence. One thing to note is that the mouse tries it's best to conserve power, so it only responds to any initial queries for a few seconds after pressing the reset button. I don't know exactly how long, but it's pretty short. Klausler makes a note of this on his site, so it must have caused him a hiccup or two. > please send me the output of hcidump. Okay, here it is. Turns out I think my batteries ran out of juice, which was causing some of the problems. I wasn't getting any response at all after all sorts of resets so I tried seeing if I could find the keyboard and it 'just worked'. I replaced the batteries and got a response from hccontrol inquiry. Just in case replacing the batteries turned out to reset it more than pressing the button I put the old batteries back in and still got nothing. When the batteries 'die' the mouse still lights up (it's optical), and apparently the radio connection goes first. Anyway, without further adue here is the hcidump output: # hcidump -x HCIDump - HCI packet analyzer ver 1.4 device: any snap_len: 65535 filter: 0x < HCI Command: Inquiry(0x01|0x0001) plen 5 33 8B 9E 05 08 > HCI Event: Command Status(0x0f) plen 4 00 01 01 04 > HCI Event: Inquiry Complete(0x01) plen 1 00 < HCI Command: Inquiry(0x01|0x0001) plen 5 33 8B 9E 05 08 > HCI Event: Command Status(0x0f) plen 4 00 01 01 04 > HCI Event: Inquiry Complete(0x01) plen 1 00 < HCI Command: Inquiry(0x01|0x0001) plen 5 33 8B 9E 05 08 > HCI Event: Command Status(0x0f) plen 4 00 01 01 04 > HCI Event: Inquiry Result(0x02) plen 15 01 A8 D6 7E F2 50 00 02 00 00 80 25 00 C3 4B > HCI Event: Inquiry Complete(0x01) plen 1 00 < HCI Command: Create Connection(0x01|0x0005) plen 13 A8 D6 7E F2 50 00 18 CC 02 00 C3 4B 01 > HCI Event: Command Status(0x0f) plen 4 00 01 05 04 > HCI Event: Connect Complete(0x03) plen 11 00 29 00 A8 D6 7E F2 50 00 01 00 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 29 00 0F 00 < ACL data: handle 0x0029 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x0040 > HCI Event: Number of Completed Packets(0x13) plen 5 01 29 00 01 00 > HCI Event: Command Complete(0x0e) plen 6 01 0D 08 00 29 00 > ACL data: handle 0x0029 flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 1 status 2 > ACL data: handle 0x0029 flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0 < ACL data: handle 0x0029 flags 0x02 dlen 12 L2CAP(s): Config req: dcid 0x0040 flags 0x clen 0 > HCI Event: Number of Completed Packets(0x13) plen 5 01 29 00 01 00 > ACL data: handle 0x0029 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0040 flags 0x result 0 clen 0 > ACL data: handle 0x0029 flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0040 flags 0x clen 4 MTU 48 > HCI Event: QoS Setup Complete(0x0d) plen 21 00 29 00 00 01 00 00 00 00 00 00 00 00 F2 2B 00 00 FF FF FF FF < ACL data: handle 0x0029 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0040 flags 0x result 0 clen 0 < ACL data: handle 0x0029 flags 0x02 dlen 24 L2CAP(d): cid 0x40 len 20 [psm 1] SDP SSA Req: tid 0x0 len 0xf pat uuid-16 0x1002 (PubBrwsGrp) max 0x aid(s) 0x - 0x cont 00 > HCI Event: Number of Completed Packets(0x13) plen 5 01 29 00 01 00 > HCI Event: Number of Completed Packets(0x13) plen 5 01 29 00 01 00 > ACL data: handle 0x0029 flags 0x02 dlen 14 L2CAP(d): cid 0x40 len 10 [psm 1] SDP SSA Rsp: tid 0x0 len 0x5 cnt 0x2 len 0x2 frm->len 0x1 n 0x0 cont 00 < ACL data: handle 0x0029 flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040 > HCI Event: Number of Completed Packets(0x13) plen 5 01 29 00 01 00 > ACL data: handle 0x0029 flags 0x02 dlen 12 L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040 ^C > do you have an open baseband connection? inquiry on the local deivce > will not show remote devices that already connected to the local device. > try to run > > # hccontrol -n hci read_connection_list > Yes, this shows I have a connection to my mouse. > you can disconnect baseband connection by hand by typing > > # hccontol -n hci disconnect > > BTW you can do > > # hccontrol help > > and > > # hccontrol help > > for more information > These give a lot more help than the man page. I managed to get 'remote_name_request' to return 'Microsoft Mouse' (yippee!), but I just arbitrarily chose and as 0. I used 'read_clock_offset' to get the clock offset. What
Re: "NTLDR missing" after 5-RELEASE install
George Hartzell wrote: > On boot I get "Loading GRUB... Please Wait..." but after that I get "GRUB > Error 17" which according to the manual means that GRUB doesn't know how to > load the selected partition. Even though when I boot from the floppy it > starts no problem and I can type commands to get it to boot Win2k Here's what I'd do. Hi everyone! I'm posting from a different email address now I've got FreeBSD back up and running. George's one-man tutorial on how to install Grub was excellent and everything is now working perfectly. Thanks to everyone who replied. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI errors
>From dmesg.boot: acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ACPI-0432: *** Error: Handler for [EmbeddedControl] returned AE_ERROR ACPI-1287: *** Error: Method execution failed, AE_ERROR Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04ff0a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 996556073 Hz CPU: Mobile AMD Athlon(tm) 4 Processor (996.56-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x661 Stepping = 1 Features=0x383f9ff AMD Features=0xc044 real memory = 335544320 (320 MB) Regards, Hugo D. Valentim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-CURRENT + cvs = panic
Practically 100% repeatable: after some CVS updates (not sure but it seems after another high HD load as well) -CURRENT panics with bwrite: buffer is not busy (in the prefious message I've attached gdb trace and so on, and nothing has changed so far). It goes on for at least several days now. Regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
Mark Murray wrote: John Polstra writes: In article <[EMAIL PROTECTED]>, Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: This is wrong. caddr_t should be uniersally replaced with void *. Not quite. There is (or at least used to be) a lot of code that assumed you could do address arithmetic on a caddr_t. You can't do that on a void *, at least not in ANSI C. I think gcc lets you do it, but it's an extension. As I have discovered. I specifically looked for this, and my misreading of the spec is now clear. :-) Yes, but relying on this during fixing out caddr_t may break use of other compilers. Now, that OpenWatcom is released, the FreeBSd port of it should follow. And maybe someone will try to compile the kernel and world with it. If that would work, this would be great, because the watcom compiler generates much better code than gcc does, even than gcc -O3 (and all known optimizations on). So long, Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's happened to CPUSTATES in /usr/include/devstat.h?
From: "Paolo Pisati" <[EMAIL PROTECTED]> Sent: Sunday, March 02, 2003 2:24 PM > i noticed it while i was compiling kdebase-3, cause > ksysguard failed. > > Add > > #include > > to devstat.h to fix it. FWIW, I had the same problem (and used the same solution) with a few other X ports, particularly icewm. --Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't sshd into box
Dear John, I am only trying to connect as a normal user. telnet etaq3 and telnet etaq3 22 and telnet etaq3 25 all come right back disconnecting me: [EMAIL PROTECTED]:/home/wayne>telnet etaq3 25 Trying 192.168.0.12... Connected to etaq3.etaq.com. Escape character is '^]'. Connection closed by foreign host. portscanner etaq3 finds ports 22, 23, 25, 110 just fine. On Sun, Mar 02, 2003 at 10:17:09PM +, John Murphy wrote: > Wayne <[EMAIL PROTECTED]> wrote: > > >I can ssh out to the world, but I can't get into the new box from the > >gateway FreeBSD box on the same home network. The gateway box properly > >lists the new box in /etc/hosts. Each box can ping the other by name > >and by ip. > > Bear in mind that (by default) you can't ssh as the super-user. You must > connect as a user (in the wheel group) and then su. > > John. -- Wayne M Barnes [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
John Polstra <[EMAIL PROTECTED]> writes: > Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > > This is wrong. caddr_t should be uniersally replaced with void *. > Not quite. There is (or at least used to be) a lot of code that > assumed you could do address arithmetic on a caddr_t. You can't do > that on a void *, at least not in ANSI C. I think gcc lets you do > it, but it's an extension. Correct, and it will break if compiled with the options we use to build kernels, but in the great majority of cases, caddr_t can be replaced with void *. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: Driver mega-commit ahead.
In message <[EMAIL PROTECTED]>, "M
aksim Yevmenkin" writes:
>Dear Poul-Henning,
>
>i think the following is not correct
>
>RCS file: /home/ncvs/src/sys/netgraph/ng_device.c,v
>retrieving revision 1.2
>diff -u -r1.2 ng_device.c
>--- netgraph/ng_device.c 2 Feb 2003 13:30:00 - 1.2
>+++ netgraph/ng_device.c 2 Mar 2003 19:48:38 -
>@@ -66,7 +66,7 @@
> /* Netgraph type */
> static struct ng_type typestruct = {
> NG_ABI_VERSION, /* version */
>- NG_DEVICE_NODE_TYPE,/* name */
>+ .d_name = NG_DEVICE_NODE_TYPE,
> ng_device_mod_event,/* modevent */
> ng_device_cons, /* constructor */
> ng_device_rcvmsg, /* receive msg */
>@@ -114,19 +114,14 @@
Damn, I thought I had caught that one.
Should be fixed now in the rev 2 of the patch I uploaded.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | 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: HEADSUP: Driver mega-commit ahead.
On Sun, Mar 02, 2003 at 02:25:55PM -0700, Scott Long wrote: > > RE@ had in principal agreed with this work, since it will make 5-STABLE > and 6-CURRENT more compatible. That's all I wanted to know. Thanks, -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
John Polstra writes: > In article <[EMAIL PROTECTED]>, > Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > > > > This is wrong. caddr_t should be uniersally replaced with void *. > > Not quite. There is (or at least used to be) a lot of code that > assumed you could do address arithmetic on a caddr_t. You can't do > that on a void *, at least not in ANSI C. I think gcc lets you do > it, but it's an extension. As I have discovered. I specifically looked for this, and my misreading of the spec is now clear. :-) M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: Driver mega-commit ahead.
Marcel Moolenaar wrote: On Sun, Mar 02, 2003 at 09:14:13PM +0100, Poul-Henning Kamp wrote: I plan to commit http://phk.freebsd.dk/patch/cdevsw.patch one of the first days of the week. Basically, it changes cdevsw initializations to use C99 sparse format, and thereby eliminates 859 lines of redundant defaultvalue initializations. I thought HEAD was in a slush mode. des' sweep and this sweep seems like the kind of changes we don't want at this time. Has this changed or did re@ approve it (both cases)? RE@ had in principal agreed with this work, since it will make 5-STABLE and 6-CURRENT more compatible. PHK should probably have noted this in the commit message. As for DES, it's been discussed quite a bit on [EMAIL PROTECTED] We probably should have been more vocal about it, but once again it's good to have it in before 5-STABLE. 5.0 seems to have been the catalyst needed to get things moving again. It went much better than expected, and is giving people a benchmark for what still needs to be done. To that end, 5.1 will probably be quite different from 5.0. If the differences between 5.1 and 5.2 aren't as drastic and widespread, then that should be a good indication that we are ready for 5-STABLE. Please remember that re@ should be kept in the loop when you plan to make large changes. Things seem to be going pretty smoothly right now, so please don't let them get out of hand. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
eUSB Multimediacard flash storage
Hi list, I'm still trying to get this drive working. I booted with a -v flag, and this the output now: Can anyone recommend any changes or patches to get this to work work? My kernel is 5.0-currrent built on March 1st. Thank you, Pat Lathem umass0: SCM Microsystems Inc. eUSB MultiMediaCard Adapter, rev 1.10/4.04, addr 2 umass0:0:0:-1: Attached to scbus0 as device 0 (probe0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (probe0:umass-sim0:0:0:0): Retrying Command (probe0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (probe0:umass-sim0:0:0:0): Retrying Command (probe0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (probe0:umass-sim0:0:0:0): Retrying Command (probe0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (probe0:umass-sim0:0:0:0): Retrying Command (probe0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (probe0:umass-sim0:0:0:0): error 5 (probe0:umass-sim0:0:0:0): Retries Exausted pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-2 device pass0: 1.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 15MB (31424 512 byte sectors: 64H 32S/T 15C) (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): error 5 (da0:umass-sim0:0:0:0): Retries Exausted (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): error 5 (da0:umass-sim0:0:0:0): Retries Exausted (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR (da0:umass-sim0:0:0:0): Retrying Command To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't sshd into box
Quoting Wayne <[EMAIL PROTECTED]>: > I have installed 5.0 into a new Dell. I have not set up anything > special yet (no firewall, no natd, etc.). > > I can ssh out to the world, but I can't get into the new box from the > gateway FreeBSD box on the same home network. The gateway box properly > lists the new box in /etc/hosts. Each box can ping the other by name > and by ip. > > I enabled telnet in inetd.conf, and I get rejected, also. > > Is there a new default connecton protection that I must turn off, or > something? [/etc/hosts.allow is the default setting, I see no answer > there.] > > [EMAIL PROTECTED]:/home/wayne>telnet etaq3 > Trying 192.168.0.12... > Connected to etaq3.etaq.com. > Escape character is '^]'. > Connection closed by foreign host. > > [EMAIL PROTECTED]:/home/wayne>ping etaq3 > PING etaq3.etaq.com (192.168.0.12): 56 data bytes > 64 bytes from 192.168.0.12: icmp_seq=0 ttl=64 time=0.402 ms When you telnet to any tcp port and you receive 'Connected to ' followed by an immediate Connection closed by foreign host, it almost always means tcp_wrappers is blocking your connection. FWIW - the 'Connected to' blurb means the 3-way TCP handshake was successful. I thought the default install has tcp_wrappers "open". Since it sounds like it's not open, add the following line to the very top of /etc/hosts.allow to effecctively disable tcp_wrappers: ALL : ALL : allow As another test... do the following: # telnet etaq3 22 Do you get an SSH banner immediately? eventually? never? --daxbert To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: Driver mega-commit ahead.
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes : >On Sun, Mar 02, 2003 at 09:26:31PM +0100, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes >> : >> >On Sun, Mar 02, 2003 at 09:14:13PM +0100, Poul-Henning Kamp wrote: >> >> >> >> I plan to commit >> >> http://phk.freebsd.dk/patch/cdevsw.patch >> >> one of the first days of the week. >> >> >> >> Basically, it changes cdevsw initializations to use C99 sparse >> >> format, and thereby eliminates 859 lines of redundant defaultvalue >> >> initializations. > >> This particular sweep gives os much better cross-branch source >> portability and therefore I think it is exactly the kind of thing >> we want before the RELENG_5 branch. > >I thought this was just syntactic sugaring and that doing it now >reduces diffs between 5-stable and 6-current (by increasing diffs >between 5-release and 5-stable) but otherwise does not change a bit? > >Do I misunderstand the effect of the patch? The intention is that we can add, delete or redefine elements without having to modify all source files. Say for instance we want to add a filedescriptor argument to d_open. Without this patch, we will have to append it at the end of cdevsw to avoid modifying all drivers sources, but since that trick was already used with kqfilter, even that doesn' save us. With this patch we simply add the field, drivers which don't know about this new option will not initialize it, and we can do the necessary compat magic in make_dev(). That would make any MFC's much more manageable, since they will only entail the actually affected files, not 145 otherwise unaffected driver source files. So call it syntactic sugar if you want, but remember that emergency rations are high on carbohydrates for a reason :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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
can't sshd into box
Dear FreeBSD, I have installed 5.0 into a new Dell. I have not set up anything special yet (no firewall, no natd, etc.). I can ssh out to the world, but I can't get into the new box from the gateway FreeBSD box on the same home network. The gateway box properly lists the new box in /etc/hosts. Each box can ping the other by name and by ip. I have tried the OpenSSH that came with the system, and I installed ssh-3.0 , and the result is the same. sshd is running on the new box. I enabled telnet in inetd.conf, and I get rejected, also. Is there a new default connecton protection that I must turn off, or something? [/etc/hosts.allow is the default setting, I see no answer there.] - Wayne - example screen output below. The new box is etaq3 -- [EMAIL PROTECTED]:/home/wayne>ssh etaq3 ssh_exchange_identification: read: Connection reset by peer [EMAIL PROTECTED]:/home/wayne>telnet etaq3 Trying 192.168.0.12... Connected to etaq3.etaq.com. Escape character is '^]'. Connection closed by foreign host. [EMAIL PROTECTED]:/home/wayne>ping etaq3 PING etaq3.etaq.com (192.168.0.12): 56 data bytes 64 bytes from 192.168.0.12: icmp_seq=0 ttl=64 time=0.402 ms 64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=0.618 ms 64 bytes from 192.168.0.12: icmp_seq=2 ttl=64 time=0.344 ms -- Wayne M Barnes [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: PATCH: typo in socreate() or i'm missing something
Dear Hackers, < said: > > Interestingly, socreate() in Lite2 always does a can-wait malloc() so > > our current soalloc(M_NOWAIT) does the same thing as Lite2 and is only > > wrong if the FreeBSD change from can-wait to "can-wait-if p != 0" > > change was needed and is still needed. > > When I initially revamped that code, I waited unconditionally and was > rewarded with an appropriate panic for sleeping in interrupt context. > I cannot speak as to whether it is still needed. well, what is the best way to proceed here? as far as i can see there are three options here: 1) leave it as it is for now 2) change it to so = soalloc(0); (i.e. never sleep) 3) revert it back to rotted so = soalloc(td != 0); in this case people like me will call socreate() with td == 0, and other will call socreate() with real td pointer or curthread. i personally do not like option 1) at all. are there any other options? suggestions? thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: Driver mega-commit ahead.
On Sun, Mar 02, 2003 at 09:26:31PM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes > : > >On Sun, Mar 02, 2003 at 09:14:13PM +0100, Poul-Henning Kamp wrote: > >> > >> I plan to commit > >>http://phk.freebsd.dk/patch/cdevsw.patch > >> one of the first days of the week. > >> > >> Basically, it changes cdevsw initializations to use C99 sparse > >> format, and thereby eliminates 859 lines of redundant defaultvalue > >> initializations. > This particular sweep gives os much better cross-branch source > portability and therefore I think it is exactly the kind of thing > we want before the RELENG_5 branch. I thought this was just syntactic sugaring and that doing it now reduces diffs between 5-stable and 6-current (by increasing diffs between 5-release and 5-stable) but otherwise does not change a bit? Do I misunderstand the effect of the patch? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADSUP: Driver mega-commit ahead.
Dear Poul-Henning,
i think the following is not correct
RCS file: /home/ncvs/src/sys/netgraph/ng_device.c,v
retrieving revision 1.2
diff -u -r1.2 ng_device.c
--- netgraph/ng_device.c2 Feb 2003 13:30:00 - 1.2
+++ netgraph/ng_device.c2 Mar 2003 19:48:38 -
@@ -66,7 +66,7 @@
/* Netgraph type */
static struct ng_type typestruct = {
NG_ABI_VERSION, /* version */
- NG_DEVICE_NODE_TYPE,/* name */
+ .d_name = NG_DEVICE_NODE_TYPE,
ng_device_mod_event,/* modevent */
ng_device_cons, /* constructor */
ng_device_rcvmsg, /* receive msg */
@@ -114,19 +114,14 @@
please fix
thanks
max
-Original Message-
From: Poul-Henning Kamp [mailto:[EMAIL PROTECTED]
Sent: Sun 3/2/2003 12:26 PM
To: Marcel Moolenaar
Cc: [EMAIL PROTECTED]
Subject:Re: HEADSUP: Driver mega-commit ahead.
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes
:
>On Sun, Mar 02, 2003 at 09:14:13PM +0100, Poul-Henning Kamp wrote:
>>
>> I plan to commit
>> http://phk.freebsd.dk/patch/cdevsw.patch
>> one of the first days of the week.
>>
>> Basically, it changes cdevsw initializations to use C99 sparse
>> format, and thereby eliminates 859 lines of redundant defaultvalue
>> initializations.
>
>I thought HEAD was in a slush mode. des' sweep and this sweep seems
>like the kind of changes we don't want at this time. Has this changed
>or did re@ approve it (both cases)?
I can't talk for DES sweep, (although I'll say that it seems like
a step in the right direction for me).
This particular sweep gives os much better cross-branch source
portability and therefore I think it is exactly the kind of thing
we want before the RELENG_5 branch.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | 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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Current Hardware Configuration Questions
- Floppy FTP install: 4.8-PreRelease works fine, but with CURRENT my laptop bogs down in the FTP get stage... Alternatively, it also doesn't find the CDROM drive after the boot stage of the install process. The only way I've gotten it to install is to copy the CDROM image to another UFS partition. I have a SONY C1VN Picturebook. In Linux, I can use "ide2=0x180,0x386", but I've been unable to apply this to CURRENT. Exactly what hints do I need to use? In 4.8Pre, it shows up as ata4. hint.ata.4.port=0x180? What about the 0x386? - IRQ/Memory Conflict? With CURRENT, running X kills my network connection. I suspected an IRQ/IOMEM conflict, the video card and pcmcia were sharing the same irq 9, but the same thing happens on my desktop... Is there a way to force hardware to specific IRQ/Memory configurations? i.e. When I installed 4.8pre, it prefers 0xd4000 and irq 10 for my pcmcia card, but CURRENT wants it to be at 0xd and irq 9. Additionally, CURRENT seems to be ignoring pccard.conf and rc.conf pccardd settings... - ANY suggestions on how to best manage hardware configurations in CURRENT? Can't wait to learn MAC, other Trusted BSD features and GEOM! :o) Thanks! Abe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: Driver mega-commit ahead.
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes : >On Sun, Mar 02, 2003 at 09:14:13PM +0100, Poul-Henning Kamp wrote: >> >> I plan to commit >> http://phk.freebsd.dk/patch/cdevsw.patch >> one of the first days of the week. >> >> Basically, it changes cdevsw initializations to use C99 sparse >> format, and thereby eliminates 859 lines of redundant defaultvalue >> initializations. > >I thought HEAD was in a slush mode. des' sweep and this sweep seems >like the kind of changes we don't want at this time. Has this changed >or did re@ approve it (both cases)? I can't talk for DES sweep, (although I'll say that it seems like a step in the right direction for me). This particular sweep gives os much better cross-branch source portability and therefore I think it is exactly the kind of thing we want before the RELENG_5 branch. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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: HEADSUP: Driver mega-commit ahead.
On Sun, Mar 02, 2003 at 09:14:13PM +0100, Poul-Henning Kamp wrote: > > I plan to commit > http://phk.freebsd.dk/patch/cdevsw.patch > one of the first days of the week. > > Basically, it changes cdevsw initializations to use C99 sparse > format, and thereby eliminates 859 lines of redundant defaultvalue > initializations. I thought HEAD was in a slush mode. des' sweep and this sweep seems like the kind of changes we don't want at this time. Has this changed or did re@ approve it (both cases)? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADSUP: Driver mega-commit ahead.
I plan to commit
http://phk.freebsd.dk/patch/cdevsw.patch
one of the first days of the week.
Basically, it changes cdevsw initializations to use C99 sparse
format, and thereby eliminates 859 lines of redundant defaultvalue
initializations.
After this patch has been committed, we will be able to add new
(variants of existing) methods to cdevsw without having to change
all device drivers to match.
This will also allow us to clean up fluff from earlier expansions,
like for instance the KQ_FILTER flag which will no longer be
necessary.
Compatibility with 4-stable could be possible if somebody volunteers
to test the necessary patches.
Included is the top of the patch file, the rest is equally boring.
Poul-Henning
This is a machine generated patch which changes all cdevsw{} initializations
to use C99 style sparse initializers and at the same time removes all the
initializations which are not needed because they are the default values.
Index: alpha/alpha/mem.c
===
RCS file: /home/ncvs/src/sys/alpha/alpha/mem.c,v
retrieving revision 1.42
diff -u -r1.42 mem.c
--- alpha/alpha/mem.c 25 Feb 2003 03:21:18 - 1.42
+++ alpha/alpha/mem.c 2 Mar 2003 19:48:33 -
@@ -80,19 +80,15 @@
#define CDEV_MAJOR 2
static struct cdevsw mem_cdevsw = {
- /* open */ mmopen,
- /* close */ mmclose,
- /* read */ mmrw,
- /* write */ mmrw,
- /* ioctl */ mmioctl,
- /* poll */ (d_poll_t *)seltrue,
- /* mmap */ memmmap,
- /* strategy */ nostrategy,
- /* name */ "mem",
- /* maj */ CDEV_MAJOR,
- /* dump */ nodump,
- /* psize */ nopsize,
- /* flags */ D_MEM,
+ .d_open = mmopen,
+ .d_close = mmclose,
+ .d_read = mmrw,
+ .d_write = mmrw,
+ .d_ioctl = mmioctl,
+ .d_mmap = memmmap,
+ .d_name = "mem",
+ .d_maj =CDEV_MAJOR,
+ .d_flags = D_MEM,
};
struct mem_range_softc mem_range_softc;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | 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: PATCH: typo in socreate() or i'm missing something
< said: > Interestingly, socreate() in Lite2 always does a can-wait malloc() so > our current soalloc(M_NOWAIT) does the same thing as Lite2 and is only > wrong if the FreeBSD change from can-wait to "can-wait-if p != 0" > change was needed and is still needed. When I initially revamped that code, I waited unconditionally and was rewarded with an appropriate panic for sleeping in interrupt context. I cannot speak as to whether it is still needed. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
éÚÇÏÔÏ×ÌÅÎÉÅ ÓÔÉÌØÎÙÈ ÓÁÊÔÏ×
Изготовление стильных сайтов любого уровня сложности и их поддержка. Цены от 500 до 5000 USD. Работают только профессионалы (не студенты). Реклама в интернете. т. (095) 275-49-84 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
What's happened to CPUSTATES in /usr/include/devstat.h?
As the subject says, i noticed it while i was compiling kdebase-3, cause ksysguard failed. Add #include to devstat.h to fix it. I hope i did it right... =P -- Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas why we can't even boot a i386 ?
Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bruce Evans writes: > >On Sun, 2 Mar 2003, Bruce Evans wrote: > >> On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: > >> > My main concern would be if the chips have the necessary "umphf" > >> > to actually do a real-world job once they're done running all the > >> > overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly > >> > expensive. > >> > >> Actually, the lack of cmpxchg8 only makes locking more expensive. It's > > > >I.e., strictly more expensive, but not much more. > > Bruce, it is not a matter of the relative expensiveness of the various > implementations of locking primitives, its a matter of the cummulative > weight of all the locks we add to the system. Bruce's "make world" benchmark gave coverage of the cumulative weight, in support of his point. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: distributed folding client panics -current
On Sun, Mar 02, 2003 at 04:09:34AM -0800, Kris Kennaway wrote: > This may already be fixed..can you try updating and see if the problem persists? > > Kris I got it again right after the client checks for new version. The world is about 1.5hrs old. Attached the kernel dump Jiawei Ye -- "Without the userland, the kernel is useless." --inspired by The Tao of ProgrammingCopyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b2036 stack pointer = 0x10:0xcd32da90 frame pointer = 0x10:0xcd32dab4 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 = 14 (swi1: net) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? Uptime: 10h44m40s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete Terminate ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Copyright (c) 1992-2003 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: Sun Mar 2 02:22:20 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CHIHIRO Preloaded elf kernel "/boot/kernel/kernel" at 0xc042. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04200a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1794555904 Hz CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.56-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 Features=0x3febf9ff real memory = 268369920 (255 MB) avail memory = 256139264 (244 MB) Allocating major#253 to "net" Pentium Pro MTRR support enabled Allocating major#252 to "pci" npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00f7550 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe800-0xebff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 rl0: port 0xbc00-0xbcff mem 0xefefff00-0xefef irq 10 at device 1.0 on pci2 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:40:95:07:53:6b miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: port 0xb800-0xb81f mem 0xefd0-0xefdf,0xe76ff000-0xe76f irq 12 at device 2.0 on pci2 fxp0: Ethernet address 00:90:27:13:a4:48 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: at device 4.0 on pci2 pci3: on pcib3 asr0: mem 0xe400-0xe5ff irq 9 at device 4.1 on pci2 asr0: major=154 asr0: DPT PM1564U3 FW Rev. 3013, 1 channel, 256 CCBs, Protocol I2O isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xff00-0xff0f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.2 (no driver attached) pci0: at device 31.3 (no driver attached) pci0: at device 31.4 (no driver attached) acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: cmd 3 failed at out byte 1 of 3 orm0: at iomem 0xe-0xe0fff,0xcc000-0xccfff,0xc-0xcbfff on isa0 pmtimer0 on isa0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ad0: 12949MB [26310/16/63] at ata0-master UDMA66 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted Waiting (max 60 second
Re: PATCH: type errors in src-tree
In article <[EMAIL PROTECTED]>, Dag-Erling Smorgrav <[EMAIL PROTECTED]> wrote: > > This is wrong. caddr_t should be uniersally replaced with void *. Not quite. There is (or at least used to be) a lot of code that assumed you could do address arithmetic on a caddr_t. You can't do that on a void *, at least not in ANSI C. I think gcc lets you do it, but it's an extension. John -- John Polstra 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: Any ideas why we can't even boot a i386 ?
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >On Sun, 2 Mar 2003, Bruce Evans wrote: > >> On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: >> >> > My main concern would be if the chips have the necessary "umphf" >> > to actually do a real-world job once they're done running all the >> > overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly >> > expensive. >> >> Actually, the lack of cmpxchg8 only makes locking more expensive. It's > > >I.e., strictly more expensive, but not much more. Bruce, it is not a matter of the relative expensiveness of the various implementations of locking primitives, its a matter of the cummulative weight of all the locks we add to the system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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: mgetty in ttys hoses system
Christoph Kukulies wrote: > I installed the /usr/ports/comms/mgetty+sendfax to get my > new servers functions completed and found after installing the > port and giving a kill -HUP 1 - the port adds the > line > cuaa0 "/usr/local/sbin/mgetty" unknown on insecure > to /etc/ttys. > > After that the system was hosed. After rebooting > the system seemed to got hung in multi user mode. > No vtys and I booted into single user. > > Found that /etc/ttys contained passwd entries instead, totally > hosed. It never happended to me that I got FS corruption > like this before. This is a well-known FreeBSD VM bug, having to do with writes to COW pages for objects mapped read-only. It happens when you modify the contents of the data areas returned by getpwent(). We had the same problem with Vixie "cron" on the InterJet; it would spam the crontab with a page of data from the passwd database. No one ever fixed it, because no one after Dyson has really bothered to fully understand the VM system, before making changes to it. You can work around it by modifying the program to copy the pwent contents (or use it's own pwent structure) instead of modifying the returned data areas. This avoids triggering the COW, where the dirty buffer gets attached to the wrong vnode. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Any ideas why we can't even boot a i386 ?
On Sun, 2 Mar 2003, Bruce Evans wrote: > On Fri, 28 Feb 2003, Poul-Henning Kamp wrote: > > > My main concern would be if the chips have the necessary "umphf" > > to actually do a real-world job once they're done running all the > > overhead of 5.0-R. The lack of cmpxchg8 makes the locking horribly > > expensive. > > Actually, the lack of cmpxchg8 only makes locking more expensive. It's I.e., strictly more expensive, but not much more. > [cycle types for Athlon1600 running 386 code] Here are whorldstone benchmarks for an Athlon. The 386 version was a whole 0.3% slower for real time (3.2% slower for system time). To get the system to run I had to unbreak panicifcpuunsupported() so that it doesn't gratuitously reject Athlons (CPUs that are upward compatible should not be rejected), and had to replace pmap.o by the non-386 version since the 386 version caused strange errors. It's not clear why the 386 version doesn't work -- the only internal difference in pmap.c is that the 386 version uses invltlb() and other versions use invlpg(). Using invlpg() would probably make things more than 0.3% slower. Selecting the best inv*() was the main optimization that we dropped when 386 support was made incompatible with support for later CPUs. world with my kernel configured for I486_CPU through I686_CPU %%% 1532 MHz AthlonXP 1600 256MB 2 ATA drives async mounted /usr/obj (src on separate drive) -- >>> elf make world completed on Sun Mar 2 16:30:55 EST 2003 (started Sun Mar 2 15:53:15 EST 2003) -- 2260.31 real 1729.55 user 326.24 sys 40208 maximum resident set size 2248 average shared memory size 1762 average unshared data size 127 average unshared stack size 14959205 page reclaims 25630 page faults 0 swaps 43481 block input operations 3963 block output operations 0 messages sent 0 messages received 5 signals received 313523 voluntary context switches 607085 involuntary context switches %%% world with my kernel configured for I386_CPU except for pmap.o %%% 1532 MHz AthlonXP 1600 256MB 2 ATA drives async mounted /usr/obj (src on separate drive) -- >>> elf make world completed on Mon Mar 3 03:00:45 EST 2003 (started Mon Mar 3 02:22:57 EST 2003) -- 2267.98 real 1730.21 user 336.73 sys 40208 maximum resident set size 2245 average shared memory size 1756 average unshared data size 127 average unshared stack size 14958931 page reclaims 26265 page faults 0 swaps 44148 block input operations 3898 block output operations 0 messages sent 0 messages received 6 signals received 313986 voluntary context switches 598687 involuntary context switches %%% Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
potential for foot-shooting with KLD's
Imagine you decided to go with modular kernel. You comment out 'device random' in your kernel-config and place 'random_load="YES"' in /boot/loader.conf. When you reboot and don't rebuild the kernel first, you have your machine unbootable - at least in case you previously had acpi in your kernel and acpi doesn't work without OS supplied dsdt (as in my case) or you need acpi as a module or any other module. The way out is to boot from install CDROM, have fixit floppy, mount the old root and remove the random.ko module. Which is pretty inconvenient, when you don't have the medias handy. The problem is that I can't ask loader not to load some module. It doesn't understand 'unset XX_load'. It doesn't work to say 'set XX_load="NO"' either. The only way I found to make it not load the modules is to 'load /boot/kernel/kernel;set module_path="";boot'. Unfortunately it doesn't help me either because I need to load special acpi_dsdt.aml which isn't then loaded either. The fix could be to be able to say 'unset XX_load' or make 'set XX_load="NO"' work. The other fix (probably more difficult to do) would be to make all modules loading/linking fail when they're statically compiled in. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Double fault with IBM microdrives and CompactFlash (LONG)
On Sat, 1 Mar 2003, Andre Guibert de Bruet wrote:
> I just tried using my FreeBSD laptop to unload pictures off of a 340MB IBM
> microdrive (Model: DMDM-10340, P/N: 22L0046) using the IBM PC Card adapter
> (P/N: 31L9315). The laptop in question is a stock Dell Latitude C800 with
> a 1Ghz P3, 512MB of RAM and a 20GB ATA66 drive.
>
> I got a double "page fault in kernel mode" message shortly after inserting
> the drive. I rebooted then tried using the same adapter with a 128MB
> Viking CompactFlash card, and I got the same problem. Now, I've used this
> adapter under Windows XP, and it works, so it's not defective. I use the
> same cardbus slots for my wi0 interface (PRISM II-based), so I know both
> slots work. I recvsup'ed to make sure that I have all the latest committed
> fixes. Here's what uname says:
> pccard1: Allocation failed for cfe 0
> ata2 at port 0x100-0x10f irq 10 function 0 config 1 on pccard1
I've since cvsup'ed, and upgraded this machine's kernel.
omikron# uname -a
FreeBSD omikron.properkernel.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Mar 2
09:29:14 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OMIKRON i386
I also enabled dumps and managed to get a clean dump:
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc013bb55 in db_fncall (dummy1=0, dummy2=0, dummy3=3999,dummy4=0xd68d0964
"@\003EÀ\f") at ../../../ddb/db_command.c:546
#2 0xc013b8d2 in db_command (last_cmdp=0xc04037c0, cmd_table=0x0,
aux_cmd_tablep=0xc03fdf94, aux_cmd_tablep_end=0xc03fdf98)at
../../../ddb/db_command.c:346
#3 0xc013b9e6 in db_command_loop () at ../../../ddb/db_command.c:470
#4 0xc013e76a in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#5 0xc0388ad1 in kdb_trap (type=12, code=0, regs=0xd68d0b34)at
../../../i386/i386/db_interface.c:166
#6 0xc039a2f2 in trap_fatal (frame=0xd68d0b34, eva=0)at
../../../i386/i386/trap.c:838
#7 0xc039a002 in trap_pfault (frame=0xd68d0b34, usermode=0, eva=0)at
../../../i386/i386/trap.c:757
#8 0xc0399b7d in trap (frame= {tf_fs = -695402472, tf_es = -1072431088, tf_ds =
-1051262960, tf_edi = -1051687936, tf_esi = 128, tf_ebp = -695399504, tf_isp =
-695399584, tf_ebx = 16, tf_edx = -1051231700, tf_ecx = -1068976384, tf_eax =
-1051231700, tf_trapno = 12, tf_err = 0, tf_eip = 0, tf_cs = 8, tf_eflags = 66118,
tf_esp = -1072345719, tf_ss = -1051231700}) at ../../../i386/i386/trap.c:444
#9 0xc038a428 in calltrap () at {standard input}:96
#10 0xc01463d3 in ata_attach (dev=0x80) at ../../../dev/ata/ata-all.c:210
#11 0xc017b24a in pccard_compat_do_attach (bus=0xc40f8500, dev=0x80)at
card_if.h:129
#12 0xc014a5bd in pccard_compat_attach (dev=0x10) at card_if.h:147
#13 0xc0254010 in device_probe_and_attach (dev=0x10) at device_if.h:39
#14 0xc0179f1f in pccard_attach_card (dev=0xc40f8500)at
../../../dev/pccard/pccard.c:243
#15 0xc0181f08 in cbb_insert (sc=0xc15a2c00) at card_if.h:66
#16 0xc0181d2b in cbb_event_thread (arg=0xc15a2c00)at
../../../dev/pccbb/pccbb.c:914
#17 0xc022b634 in fork_exit (callout=0xc0181cb0 , arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:871
(kgdb) list ../../../dev/ata/ata-all.c:210
205 if (ch->devices & ATA_ATAPI_MASTER)
206 if (ata_getparam(&ch->device[MASTER], ATA_C_ATAPI_IDENTIFY))
207 ch->devices &= ~ATA_ATAPI_MASTER;
208 #ifdef DEV_ATADISK
209 if (ch->devices & ATA_ATA_MASTER)
210 ad_attach(&ch->device[MASTER]);
211 if (ch->devices & ATA_ATA_SLAVE)
212 ad_attach(&ch->device[SLAVE]);
213 #endif
214 #if DEV_ATAPIALL
File versions:
src/sys/dev/ata/ata-all.c 1.167
src/sys/dev/ata/ata-all.h 1.59
src/sys/dev/pccard/card_if.m 1.21
src/sys/dev/pccbb/pccbb.c 1.65
src/sys/kern/device_if.m 1.8
src/sys/kern/kern_fork.c 1.186
src/sys/pccard/pccard.c 1.156
The kernel config file that I'm using can be found at:
http://siliconlandmark.com/staff/andre/files/OMIKRON
If there's anything else that could be helpful, please don't hesitate to
ask! :-)
Thanks again,
> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
On Sun, 2 Mar 2003, Jens Rehsack wrote:
JR>Barney Wolff wrote:
JR>> This is an example of what I was pointing out:
JR>>
JR>> On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
JR>> ...
JR>>
JR>>>@@ -1444,22 +1420,19 @@
JR>>> *none- response sent
JR>>> *
JR>>> */
JR>>>-void
JR>>>-send_resp ( intf, Hdr, resp )
JR>>>- int intf;
JR>>>- Snmp_Header *Hdr;
JR>>>- u_char *resp;
JR>>>+static void
JR>>>+send_resp ( const int intf, Snmp_Header *Hdr, char *resp )
JR>>> {
JR>>> int n;
JR>>>
JR>>>- if ( ilmi_fd[intf] > 0 ) {
JR>>>- n = write ( ilmi_fd[intf], (caddr_t)&resp[1], resp[0] );
JR>>>+ if ( ilmi_fd[intf] > 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range?
*/
JR>>>+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
JR>>
JR>> ...
JR>>
JR>> Here's a case where it matters whether something is u_char or char.
JR>> write(2) takes a size_t as its third arg, and extension of a char to
JR>> that may not be the same as for u_char, for example on Sparc. If the
JR>> response is ever >127 bytes, this will fail. You're going to have to
JR>> look carefully at how things are used to see when char is appropriate
JR>> and when u_char is necessary.
JR>>
JR>
JR>That is really right, but for those check I have to know more 'bout ATM,
JR>right? I just have detected some compiler errors using
JR>-finline-functions (yes, I'm playing with optimization options :-)). If
JR>you know a real good online-reference, one fine day I'll check it and
JR>check the entire ilmid.c code for valid signment.
Go to www.atmforum.com and look at the Standards page. You will find the
ILMI 4.0 standard there. But beware, if you are not used to read
telecommunication standards, you will be confused :-)
For ILMI you will also need the relavant SNMP RFCs and, maybe, the ASN.1
doc (don't remember exactly should be one of the Z.* ITU-T standards).
harti
JR>
JR>Jens
JR>
JR>
JR>To Unsubscribe: send mail to [EMAIL PROTECTED]
JR>with "unsubscribe freebsd-current" in the body of the message
JR>
--
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: distributed folding client panics -current
On Sun, 2003-03-02 at 12:25, Donn Miller wrote: > Kris Kennaway wrote: > > --6sX45UoQRIJXqkqR > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > > > This may already be fixed..can you try updating and see if the problem persists? > > Yes. I've also had problems with my laptop freezing when using > gtk-gnutella. After the fixes (I'm now at version 1.198 of > tcp_input.c), my laptop takes a lot longer to panic while running > gnutella, but it still happens nonetheless. Here is a little backtrace: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x20 > fault code= supervisor read, page not present > instruction pointer = 0x8:0xc01e3fb6 > stack pointer = 0x10:0xcd298a90 > frame pointer = 0x10:0xcd298ab4 > 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 = 12 (swi1: net) > trap number = 12 > panic: page fault > > syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? > Uptime: 48m8s > Dumping 255 MB > ata0: resetting devices .. > done > 16[CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to abort] 48 64 80 > 96 112 128 144 160 176 192 208 224 240 Just chiming in with a me-too, for LimeWire. I also am seeing this problem. I'm cvsupping and rebuilding now, my build is a few days old. Fish To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
Dag-Erling Smorgrav writes: > Jens Rehsack <[EMAIL PROTECTED]> writes: > > Of course. Very often in ilmid.c the type caddr_t was used, and nearly > > the same count of 'const char *'s was used. I've searched the include > > files for caddr_t (core address) and found it defined as 'char *', so > > I decided to used commonly caddr_t - maybe later I check which of them > > could be changed into 'c_caddr_t' for being const. But You can of > > couse replace all 'caddr_t' which 'char *'. > > This is wrong. caddr_t should be uniersally replaced with void *. I'm currently doing this for kicks (Well, actually because it kills a botload of warnings, lint and otherwise). Once make world is working again, I'll put up a patch. My approach is to typedef caddr_t to void*, and then fix the errors this causes. So far, they are all no-brainers; mainly function prototypes that are inconsistent with their definitions. There are a few places where caddr_t is assumed to point to char. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCH: type errors in src-tree
Dag-Erling Smorgrav wrote: Jens Rehsack <[EMAIL PROTECTED]> writes: Of course. Very often in ilmid.c the type caddr_t was used, and nearly the same count of 'const char *'s was used. I've searched the include files for caddr_t (core address) and found it defined as 'char *', so I decided to used commonly caddr_t - maybe later I check which of them could be changed into 'c_caddr_t' for being const. But You can of couse replace all 'caddr_t' which 'char *'. This is wrong. caddr_t should be uniersally replaced with void *. Good to know. I think I have done it where it's possible, and where really (unsigned) char *(*) was required, I've used that. There're some places in code where I'm not sure about it's being correct, but that has nothing to do with char */void *. DES Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: distributed folding client panics -current
Kris Kennaway wrote:
--6sX45UoQRIJXqkqR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
This may already be fixed..can you try updating and see if the problem persists?
Yes. I've also had problems with my laptop freezing when using
gtk-gnutella. After the fixes (I'm now at version 1.198 of
tcp_input.c), my laptop takes a lot longer to panic while running
gnutella, but it still happens nonetheless. Here is a little backtrace:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x20
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01e3fb6
stack pointer = 0x10:0xcd298a90
frame pointer = 0x10:0xcd298ab4
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 = 12 (swi1: net)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 48m8s
Dumping 255 MB
ata0: resetting devices ..
done
16[CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to abort] 48 64 80
96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:239
#1 0xc01ee472 in boot (howto=260) at ../../../kern/kern_shutdown.c:371
#2 0xc01ee6d3 in panic () at ../../../kern/kern_shutdown.c:542
#3 0xc0232a22 in bwrite (bp=0xc7799140) at ../../../kern/vfs_bio.c:795
#4 0xc0234529 in vfs_bio_awrite (bp=0xc7799140) at
../../../kern/vfs_bio.c:1692
#5 0xc02e5fca in ffs_fsync (ap=0xcd298898) at
../../../ufs/ffs/ffs_vnops.c:257
#6 0xc02e50b7 in ffs_sync (mp=0xc25d9600, waitfor=2, cred=0xc0eb5f00,
td=0xc03a6e60)
at vnode_if.h:612
#7 0xc024939b in sync (td=0xc03a6e60, uap=0x0) at
../../../kern/vfs_syscalls.c:138
#8 0xc01ee05c in boot (howto=256) at ../../../kern/kern_shutdown.c:280
#9 0xc01ee6d3 in panic () at ../../../kern/kern_shutdown.c:542
#10 0xc03459f2 in trap_fatal (frame=0xcd298a50, eva=0) at
../../../i386/i386/trap.c:843
#11 0xc03456d2 in trap_pfault (frame=0xcd298a50, usermode=0, eva=32)
at ../../../i386/i386/trap.c:757
#12 0xc03451c0 in trap (frame=
{tf_fs = -1027342312, tf_es = 16, tf_ds = 16, tf_edi =
-1058231728, tf_esi = 0, tf_ebp = -852915532, tf_isp = -852915588,
tf_ebx = -1069851860, tf_edx = -1058231728, tf_ecx = -1034102852, tf_eax
= 1, tf_trapno = 12, tf_err = 0, tf_eip = -1071759434, tf_cs = 8,
tf_eflags = 66050, tf_esp = 16, tf_ss = -1071125744}) at
../../../i386/i386/trap.c:444
#13 0xc0335398 in calltrap () at {standard input}:96
#14 0xc0278859 in tcp_input (m=0xc0ecaa50, off0=20) at
../../../netinet/tcp_input.c:2324
#15 0xc0271736 in ip_input (m=0xc0ed7900) at ../../../netinet/ip_input.c:947
#16 0xc0271822 in ipintr () at ../../../netinet/ip_input.c:965
#17 0xc02626af in swi_net (dummy=0x0) at ../../../net/netisr.c:97
#18 0xc01da321 in ithread_loop (arg=0xc0ec8280) at
../../../kern/kern_intr.c:536
#19 0xc01d9223 in fork_exit (callout=0xc01da150 , arg=0x0,
frame=0x0)
at ../../../kern/kern_fork.c:871
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: distributed folding client panics -current
This may already be fixed..can you try updating and see if the problem persists? Kris pgp0.pgp Description: PGP signature
Re: PATCH: type errors in src-tree
Jens Rehsack <[EMAIL PROTECTED]> writes: > Of course. Very often in ilmid.c the type caddr_t was used, and nearly > the same count of 'const char *'s was used. I've searched the include > files for caddr_t (core address) and found it defined as 'char *', so > I decided to used commonly caddr_t - maybe later I check which of them > could be changed into 'c_caddr_t' for being const. But You can of > couse replace all 'caddr_t' which 'char *'. This is wrong. caddr_t should be uniersally replaced with void *. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
elf_loadfile: kernel already loaded
Hi, (Trying to boot an alternate kernel on FreeBSD/i386 with normal loader running at a console, loading kernel from a disk.) It looks like after I "unload" the default kernel, and try to "load" a new one, when I go to "boot", loader is trying to load some other kernel, and I'm not sure why, but I get the "elf_loadfile: kernel already loaded", I was trying to fix this on my p4 branch by adding some printfs to figure out what it was trying to load, and since I didn't have libstand around, it threw a fit at me during the compile and I gave up, so I figured I'd just mail here and ask if anyone has seen what I'm talking about, or knows if it is fixed, or how to fix it. Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - /* XXX Nothing to see here, now. */ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mgetty in ttys hoses system
I installed the /usr/ports/comms/mgetty+sendfax to get my new servers functions completed and found after installing the port and giving a kill -HUP 1 - the port adds the line cuaa0 "/usr/local/sbin/mgetty" unknown on insecure to /etc/ttys. After that the system was hosed. After rebooting the system seemed to got hung in multi user mode. No vtys and I booted into single user. Found that /etc/ttys contained passwd entries instead, totally hosed. It never happended to me that I got FS corruption like this before. I took out the mgetty entry and live without fax at the moment but hope to find a solution soon. Just install the mgetty+sendfax port in a -current system answer all the questions in the setup dialog with defaults and kill -HUP 1 and you'll be left with a hosed system. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: old serial RS-232 pccard and wi driver.
Can you run a small test? Can you build a kernel w/o wi? Further, can you do sysctl hw.pccard.cis_debug=1 before you insert the card (or put the hw=1 part in /boot/loader.conf) and send me the result? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: why libkvm not implement read from user memory space
On Sunday 02 March 2003 17:12, Bruce Evans wrote: > On Sun, 2 Mar 2003, Jun Su wrote: > > I am adding some new feature to the kgdb. I am not sure why the libkvm > > doesn't implement reading from memory space when checking core dump. Who > > can give some comments on this? If it is possible, I will try to > > implement it. > > It was lost when libkvm was converted to use procfs (reading from > /proc//mem instead of from kmem). procfs is often considered > harmful for even more reasons than this, but replacing it by sysctls > tends to break support for dead kernels even more since sysctl() is > completely unlike read(). > > Bruce We can use the same method which libkvm read kernel memory space when in core dump to implemt the same thing for user memory space. Currently, I am cosidering the feature for debug core dump or debug remote machine more than debug /dev/mem. I think it is possible. Am I right? Jun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: why libkvm not implement read from user memory space
On Sun, 2 Mar 2003, Jun Su wrote: > I am adding some new feature to the kgdb. I am not sure why the libkvm doesn't > implement reading from memory space when checking core dump. Who can give > some comments on this? If it is possible, I will try to implement it. It was lost when libkvm was converted to use procfs (reading from /proc//mem instead of from kmem). procfs is often considered harmful for even more reasons than this, but replacing it by sysctls tends to break support for dead kernels even more since sysctl() is completely unlike read(). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
