Re: SCHED_ULE oddities
On Fri, 28 Feb 2003, Kris Kennaway wrote: On Fri, Feb 28, 2003 at 11:24:53AM -0800, James Satterfield wrote: First off, I found SCHED_ULE to be very slow. More importantly, the two times that I rebooted while running it, shutdown failed to sync the disks. On the second reboot, I had just installed a new kernel. The results of this were ugly. /boot/kernel and /boot/kernel.old disappeared. I've since gotten the box back up and running using a SCHED_4BSD kernel and I no longer have these sync problems. It's still inoperable for me as well..I guess Jeff is busy at the moment. Jeff agreed with that when I sent him a bug report about #!/bin/sh while :; do :; done hanging the system (this gives an unkillable shell, and no other user processes can run). He said that he was going to announce this, but I haven't seen anything. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Me Too: HPT372 UDMA detection problem on current (was Re: High %interrupt when building world)
It seems Shizuka Kudo wrote: --- Bruce Cran [EMAIL PROTECTED] wrote: Just to add to this, when I run the above 'dd' command, I see top reporting 35-40% interrupt usage on the drive on the RAID controller, while it's 3-5% for the drive on the VIA controller, and the drive itself is: 0 READY ad4: 58644MB IC35L060AVER07-0 [119150/16/63] at ata2-master UDMA100 Bruce Cran To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I have sysctl -a showing hw.ata.ata_dma: 1, but atacontrol mode showing PIO4 for the drives attached to HP370A. Setting them to mode udma6 was just ignored. Fixed! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HPT372 UDMA detection problem on current
It seems Akinori MUSHA wrote: Hi, Using the latest CURRENT on my box, the ata driver fails to enable UDMA for the ATA133 disks connected to an on-board HPT372 controller. Besides, UDMA is not enabled for the CD/DVD-ROM drive which is capable of UDMA4 either, but this may be a feature or a default, I guess. Fixed! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HPT372 UDMA detection problem on current
At Sat, 1 Mar 2003 10:34:50 +0100 (CET), Soeren Schmidt wrote: Using the latest CURRENT on my box, the ata driver fails to enable UDMA for the ATA133 disks connected to an on-board HPT372 controller. Besides, UDMA is not enabled for the CD/DVD-ROM drive which is capable of UDMA4 either, but this may be a feature or a default, I guess. Fixed! Thanks! Now the two disks are running in UDMA6 and the DVD drive in UDMA4 properly. -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp It went right by me -- At the time it went over my head I was looking out the window.. I should have looked at your face instead To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
wi0 - need help
I still havn't yet got my wireless lan working after upgrade to 5.0-current I applied a wi timeout patch of yesterday but the kernel message is still there (tx failed). I disabled all firewalling for the moment to have nothing in the way that might occlude the problem. The control lights at both WLAN cards are flashing as normal but no packets seem to cross the interface. On my notebook (which has been held constant operating system release wise) I see that the interface wi0 has correct IP (not by DHCP, hard wired per ifconfig) wicontrol doesn't look suspicious ether. Only, when I say ifconfig wi0 I get status: no carrier ssid 1: Not sure whether this is normal? Help please. -- 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: PATCH: typo in socreate() or i'm missing something
On Fri, 28 Feb 2003, Maksim Yevmenkin wrote:
[About creeping bitrot:]
so = soalloc(p != 0);
--
so = soalloc(td != 0);
--
so = soalloc(M_NOWAIT);
[and proposed fixes:]
--
so = soalloc(0);
or --
so = soalloc(1);
I see, however I find it very confusing to use M_NOWAIT just because
it is defined as 1. I'm sure there are plenty other defines that can
be used :) Why M_NOWAIT? Why just not write soalloc(1)? When I was
looking at the code I got the impression that soalloc() should not
sleep.
I think the translation to M_NOWAIT was just a mistake.
Changing it to your version:
so = soalloc(M_NOWAIT);
huh? I hope you meant 0 here :) That
is what I did in my patch. Otherwise I'm deeply confused :)
Oops. I meant 0.
is safer since it assumes the worst case (that socreate() is called in
non-process context and/or with locks held), but it leaves soalloc()'s
interface bogus (it's waitfor arg is always 0).
Right, but isn't soalloc() interface bogus already? It's waitok
arguments is always set to 1. As far as I can tell there only two
functions that call soalloc(): socreate() and sonewconn(). BTW
Actually, the arg is currently always 0 in sonewconn() and always 1
(M_NOWAIT) in socreate().
sonewconn() calls soalloc(0).
tcp_input() is a critical caller of sonewconn() and it obviously shouldn't
sleep. But sonewconn() is called from process context elsewhere.
sonewconn() has used a no-wait malloc() since at least 4.4Lite2 (in Lite2
there is no soalloc() and the malloc() is done directly in sonewconn()).
I think the call from tcp_input() is the usual case and/or no one cared
to distinguish the other cases.
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. I hope that the author of this
change (wollman?) will respond. ISTR some discussion about loss of
this change when the change to soalloc(M_NOWAIT) was made, but it
didn't affect the result.
In my code I open socket from inside kernel, i.e. I call socreate()
directly with mutex held. This gives me could sleep with WITNESS
warning. I could make the mutex sleepable, but, frankly, there is
no reason to do so. It is not the end of the world for my code if
I can't create a socket.
That's a better reason for making things simple by not permitting
sleeping. We already do it in sonewconn().
Perhaps socreate() could accept another flag that tell it where
it can sleep or not. Is there any other/better way?
A flag seems to be needed if we actually care. I think we don't want
to go that way. Many functions would have to be changed to pass the
flag for the flag to actually work in all cases. Locks make the problem
even more cases. It is difficult for functions to know which locks
all of their callers may or do hold without passing around even more
flags.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: wi0 - need help
On Sat, Mar 01, 2003 at 12:03:12PM +0100, Christoph Kukulies wrote: I still havn't yet got my wireless lan working after upgrade to 5.0-current I applied a wi timeout patch of yesterday but the kernel message is still there (tx failed). The patch is unrelated to the tx failed message. On my notebook (which has been held constant operating system release wise) I see that the interface wi0 has correct IP (not by DHCP, hard wired per ifconfig) wicontrol doesn't look suspicious ether. Be precise. What does wicontrol give? status: no carrier ssid 1: Did you do `wicontrol -i wi0 -p 1'? -- 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: Me Too: HPT372 UDMA detection problem on current (was Re: High % interrupt when building world)
--- Soeren Schmidt [EMAIL PROTECTED] wrote: It seems Shizuka Kudo wrote: I have sysctl -a showing hw.ata.ata_dma: 1, but atacontrol mode showing PIO4 for the drives attached to HP370A. Setting them to mode udma6 was just ignored. Fixed! -Søren Søren, Thanks, my drives are now running at udma100. top interrupt % now drops to 5% during a buildworld. regards, __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Is there a IPFIREWALL sublist?
I'm adding IPF to a set of 5.0 boxen, and I'm sure to have questions. Anyone who's done this please drop me a note, I'm on list, but in digest mode, and Saturday is a work-day-from-home. Has anyone noticed a persistent reset-from-peer problem with 5.0? I'm behind on reading -CURRENT... Eric 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 ?
Hi, At 21:06 28/2/03, M. Warner Losh wrote: [...] We have some a few embedded systems coming back from the field soon and I plan on trying some tests on them (they are amd 386, so might not be good for you). [etc] IIRC AMD had a mask deal with Intel for the 386, so should be OK. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wi0 - need help
In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : status: no carrier : ssid 1: : : Did you do `wicontrol -i wi0 -p 1'? I've found that the new driver really really really hates the old wicontrol interface when the commands are also present in the ifconfig interface. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Volunteer with genuine i386 cpu lots of time wanted.
On Thu, Feb 27, 2003 at 05:05:43PM -0500, John Baldwin wrote: On 27-Feb-2003 Mike Barcroft wrote: John Baldwin [EMAIL PROTECTED] writes: Fixed. Apparently people don't compile kernels for 80386's very often. Maybe LINT should be building I386 instead of more modern processors. That would turn off a lot of the CPU options that LINT covers. You would lose more than you gain. Should I add the nocpu option to config(8)? :-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Any ideas why we can't even boot a i386 ?
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 hard to say how long cmpxchg8 would take on i386's if i386's had it, but it involves memory accesses which i386's are especially poor at, so I guess it would take about 2/3 as long as the main extra instructions that we use in the CPU_I386 case (pushfl: 4 cycles; cli: 3 cycles; popfl: 5 cycles). Actual testing on an Athlon1600XP in userland for the core of mtx_lock_*() + mtx_unlock_*(), namely atomic_cmpset_acq_ptr() + atomic_cmpset_rel_ptr(), run in a loop (cycle counts include loop overhead): 10 cycles in the !CPU_i386 case 42 cycles in the CPU_I386 case 36 cycles in the CPU_I386 case with cli removed 12 cycles in the CPU_I386 case with cli removed and popfl changed to addl $4,%%esp 9 cycles in the CPU_I386 case with pushfl, cli and popfl removed So the i386 code is almost the same speed on AthlonXP's in user mode except for the expensive cli and popfl instructions. However, these instructions aren't so relatively expensive on plain i386's; i386's are just generally slow and their privileged instructions aren't much slower than their integer instructions. The relative slowdown for the full mtx_*lock*() functions would be smaller since these functions do more. mtx_unlock_spin() uses atomic_store_rel_ptr() so it doesn't go near cmpxchg8 or cli and the above times the acquire/release times are almost twice as small as above. Bruce 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
Bruce Evans wrote: On Fri, 28 Feb 2003, Maksim Yevmenkin wrote: sonewconn() calls soalloc(0). tcp_input() is a critical caller of sonewconn() and it obviously shouldn't sleep. But sonewconn() is called from process context elsewhere. sonewconn() has used a no-wait malloc() since at least 4.4Lite2 (in Lite2 there is no soalloc() and the malloc() is done directly in sonewconn()). I think the call from tcp_input() is the usual case and/or no one cared to distinguish the other cases. The interesting case in the tcp_input() path is an outstanding accept call, in which a new connection is created at interrupt (in LRP) o NETISR (in traditional, livelockable FreeBSD). In general, the blocking is done in order to get a process (or now thread, I guess) context from which to obtain a cred for the newly created socket. I've discussed my own approach to this problem with both Jeffrey Hsu and Jonathan Lemon, and I think it's pretty clever: don't get the credential from the process (thread). So how do you get the same/right credential? Easy. You cannot accept except on an outstanding listen socket; so copy the cred from the listening socket, which *is* in scope, even if p == 0 (or td == 0). I believe that addresses the problem case... 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Is there a IPFIREWALL sublist?
Eric Brunner-Williams in Portland Maine wrote: I'm adding IPF to a set of 5.0 boxen, and I'm sure to have questions. Anyone who's done this please drop me a note, I'm on list, but in digest mode, and Saturday is a work-day-from-home. Has anyone noticed a persistent reset-from-peer problem with 5.0? I'm behind on reading -CURRENT... freebsd-ipfw -- 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 ?
Bob Bishop wrote: At 21:06 28/2/03, M. Warner Losh wrote: [...] We have some a few embedded systems coming back from the field soon and I plan on trying some tests on them (they are amd 386, so might not be good for you). [etc] IIRC AMD had a mask deal with Intel for the 386, so should be OK. Are you sure that AMD did not use the IBM Blue Lightening core? I'm pretty sure that there are a huge number of embedded controllers that used the Intel 386GX macrocell, though... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wi0 - need help
On Sat, Mar 01, 2003 at 03:18:49AM -0800, Marcel Moolenaar wrote: On Sat, Mar 01, 2003 at 12:03:12PM +0100, Christoph Kukulies wrote: I still havn't yet got my wireless lan working after upgrade to 5.0-current I applied a wi timeout patch of yesterday but the kernel message is still there (tx failed). The patch is unrelated to the tx failed message. On my notebook (which has been held constant operating system release wise) I see that the interface wi0 has correct IP (not by DHCP, hard wired per ifconfig) wicontrol doesn't look suspicious ether. Be precise. What does wicontrol give? status: no carrier ssid 1: Did you do `wicontrol -i wi0 -p 1'? Yes, yes. I reverted back to my old box after I got panics also on my new 5.0-current server this afternoon. I will try Warners 1MBps patch right now with the new box (had so much trouble with the old box suddenly that I again reverted to the new server and I think I have decided to cut all safety ropes now and am prepared for free fall :-) If tha patch still fails I come back with posting my wicontrol settings etc. But I already found that the ifconfig info was the same strange looking in either case, the working and the not working, so that was leading in the wrong direction. later... -- 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: PATCH: type errors in src-tree
Sorry for resending (3rd time), but I've found a small typo in the patch
of sbin/atm/ilmid/ilmid.c
Jens
--- sbin/atm/ilmid/ilmid.c.orig Wed Jan 1 18:48:45 2003
+++ sbin/atm/ilmid/ilmid.c Sat Mar 1 13:29:05 2003
@@ -162,7 +162,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +173,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +185,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -279,7 +279,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -292,7 +292,7 @@
* TRAP generic trap types
*/
char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +320,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char *ilmi_ident_str = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,7 +338,7 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
+void set_reqid( caddr_t, uint32_t );
void Increment_DL( int );
void Decrement_DL( int );
@@ -376,7 +379,7 @@
/*
* Utility to pretty print buffer as hex dumps
- *
+ *
* Arguments:
* bp - buffer pointer
* len - length to pretty print
@@ -387,10 +390,10 @@
*/
void
hexdump ( bp, len )
- u_char *bp;
- int len;
+ caddr_t bp;
+ uint32_tlen;
{
- int i, j;
+ uint32_ti, j;
/*
* Print as 4 groups of four bytes. Each byte is separated
@@ -443,7 +446,7 @@
* bufp- pointer to buffer pointer
* plen- pointer to PDU length or NULL if not a concern
*
- * Returns:
+ * Returns:
* bufp- updated buffer pointer
* plen- (possibly) adjusted pdu length
* len - decoded length
@@ -451,21 +454,21 @@
*/
int
asn_get_pdu_len ( bufp, plen )
- u_char **bufp;
- int *plen;
+ caddr_t *bufp;
+ uint32_t*plen;
{
- u_char *bp = *bufp;
- int len = 0;
- int i, b;
+ caddr_t bp =*bufp;
+ uint32_tlen = 0;
+ uint32_ti, b;
b = *bp++;
if ( plen )
- (*plen)--;
-if ( b 0x80 ) {
- for ( i = 0; i (b ~0x80); i++ ) {
+ --(*plen);
+ if ( b 0x80 ) {
+ for ( i = 0; i (b ~0x80); ++i ) {
len = len * 256 + *bp++;
if ( plen )
- (*plen)--;
+ --(*plen);
}
} else
len = b;
@@ -492,12 +495,12 @@
*/
int
asn_get_encoded ( bufp, len )
- u_char **bufp;
- int *len;
+ caddr_t *bufp;
+ uint32_t*len;
{
- u_char *bp = *bufp;
- int val = 0;
- int l = *len;
+ caddr_t bp = *bufp;
+ int val = 0; /* FIXME: signed? sure? */
+ uint32_tl = *len;
/*
* Keep going while high bit is set
@@ -507,7 +510,7 @@
* Each byte can represent 7 bits
*/
val = ( val 7 ) + ( *bp ~0x80 );
- l--;
+ --l;
} while ( *bp++ 0x80 );
*bufp = bp; /* update buffer pointer */
@@ -526,28 +529,28 @@
* plen- pointer to PDU length or NULL if not a concern
*
* Returns:
- * bufp- updated buffer pointer
+ * bufp- updated buffer pointer
* plen- (possibly) updated PDU length
* val - value of encoded
Double fault with IBM microdrives and CompactFlash (LONG)
Hi, 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: FreeBSD 5.0-CURRENT #0: Sat Mar 1 11:04:18 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OMIKRON The following messages print out when the double faults occur. I didn't have a serial console hooked up at the time, so I copied what was on the screen as best I could... :-) pccard1: Allocation failed for cfe 0 ata2 at port 0x100-0x10f irq 10 function 0 config 1 on pccard1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xd68d0b74 frame pointer = 0x10:0xd68d0bb0 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 = 9 (cbb1) kernel: type 12 trap, code=0 Stopped at 0: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0388d20 stack pointer = 0x10:0xd68d0978 frame pointer = 0x10:0xd68d097c 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 = 9 (cbb1) kernel: type 12 trap, code=0 db tr Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0388d20 stack pointer = 0x10:0xd68d0860 frame pointer = 0x10:0xd68d0864 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 9 (cbb1) kernel: type12 trap, code=0 db show registers cs 0x8 ds 0xc1560010 es 0xc0140010 an_attach+0x450 fs 0xd68d0018 ss 0x10 eax0xc156332c ecx0xc048b8b8 edx0xc156332c ebx 0x10 esp0xd68d0b74 ebp0xd68d0bb0 esi 0x80 edi0xc1508200 eip 0 efl 0x10246 dr0 0 dr1 0 dr2 0 dr3 0 dr40x0ff0 dr5 0x400 dr60x0ff0 dr7 0x400 0: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:c0388d20 stack pointer = 0x10:0xd68d0878 frame pointer = 0x10:0xd68d087c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1 def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 9 (cbb1) kernel: type 12 trap code=0 dbcall sync 0 db If I do not remove the card, doing a call sync never finishes. It appears as if this problem is 100% reproducible. Any ideas? Thanks, 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: wi0 - need help
On Sat, Mar 01, 2003 at 06:08:27AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : status: no carrier : ssid 1: : : Did you do `wicontrol -i wi0 -p 1'? As already said, I did that and the wicontrol output between the good and the bad situation doesn't differ in no way. Warner, I applied the patch and no change. I cannot ping the server from the notebook nor other direction . When I do a tcpdump -i wi0 and then ping my notebook in the WLAN all I see is: www# tcpdump -i wi0 tcpdump: listening on wi0 18:56:35.367918 arp who-has kukubook2k tell 192.168.254.1 18:56:36.375996 arp who-has kukubook2k tell 192.168.254.1 18:56:37.386014 arp who-has kukubook2k tell 192.168.254.1 18:56:38.396032 arp who-has kukubook2k tell 192.168.254.1 I've found that the new driver really really really hates the old wicontrol interface when the commands are also present in the ifconfig interface. How does one specify the commands in the ifconfig interface? This is what I used to invoke from /etc/rc.local: /usr/sbin/wicontrol -i wi0 -n kuku /usr/sbin/wicontrol -i wi0 -p 1 /usr/sbin/wicontrol -i wi0 -c 1 /usr/sbin/wicontrol -i wi0 -s bgate ifconfig wi0 192.168.254.1 netmask 255.255.255.0 Maybe I'm doing something essentially wrong that worked under 4.4 (first release that had netgraph, I believe) and now has to be done differently. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wi0 - need help
In message: [EMAIL PROTECTED] Christoph P. Kukulies [EMAIL PROTECTED] writes: : Warner, I applied the patch and no change. marcel's patch, or my patch? : How does one specify the commands in the ifconfig interface? : This is what I used to invoke from /etc/rc.local: : : /usr/sbin/wicontrol -i wi0 -n kuku : /usr/sbin/wicontrol -i wi0 -p 1 : /usr/sbin/wicontrol -i wi0 -c 1 : /usr/sbin/wicontrol -i wi0 -s bgate : ifconfig wi0 192.168.254.1 netmask 255.255.255.0 (assuming that you are using a real access point, or a freebsd server in hostap mode): ifconfig wi0 192.168.254.1 netmask 255.255.255.0 ssid kuku stationname \ bgate media DS/11Mbps If you are trying to do a IBSS network, and are running 5.x, you'd want to do something like: ifconfig wi0 192.168.254.1 netmask 255.255.255.0 ssid kuku stationname \ bgate media DS/11Mbps mediaopt adhoc [*] and ifconfig wi0 192.168.254.2 netmask 255.255.255.0 ssid kuku stationname \ kukulap media DS/11Mbps mediaopt adhoc[*] [*] adhoc is spelled ibss-create on 4.x Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk]
On Thu, Feb 27, 2003 at 11:53:02AM +0200, Vallo Kallaste vallo wrote: The vinum R5 and system as a whole were stable without softupdates. Only one problem remained after disabling softupdates, while being online and user I/O going on, rebuilding of failed disk corrupt the R5 volume completely. Yes, we've fixed a bug in that area. It had nothing to do with soft updates, though. Oh, that's very good news, thank you! Yes, it had nothing to do with soft updates at all and that's why I had the remained after in the sentence. Don't know is it fixed or not as I don't have necessary hardware at the moment. The only way around was to quiesce the volume before rebuilding, umount it, and wait until rebuild finished. I'll suggest extensive testing cycle for everyone who's going to work with vinum R5. Concat, striping and mirroring has been a breeze but not so with R5. IIRC the rebuild bug bit any striped configuration. Ok, I definitely had problems only with R5, but you certainly know much better what it was exactly. I'll need to lend 50-pin SCSI cable and test vinum again. Will it matter on what version of FreeBSD I'll try on? My home system runs -current of Feb 5, but if you suggest -stable for consistent results, I'll do it. So I did. Loaned two SCSI disks and 50-pin cable. Things haven't improved a bit, I'm very sorry to say it. The entire test session (script below) was done in single user. To be fair, I did tens of them, and the mode doesn't matter. Complete script: Script started on Sat Mar 1 19:54:45 2003 # pwd /root # dmesg 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 Feb 2 16:16:49 EET 2003 [EMAIL PROTECTED]:/usr/home/vallo/Kevad-5.0 Preloaded elf kernel /boot/kernel/kernel at 0xc0516000. Preloaded elf module /boot/kernel/vinum.ko at 0xc05160b4. Preloaded elf module /boot/kernel/ahc_pci.ko at 0xc0516160. Preloaded elf module /boot/kernel/ahc.ko at 0xc051620c. Preloaded elf module /boot/kernel/cam.ko at 0xc05162b4. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 132955356 Hz CPU: Pentium/P54C (132.96-MHz 586-class CPU) Origin = GenuineIntel Id = 0x526 Stepping = 6 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 67108864 (64 MB) avail memory = 59682816 (56 MB) Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem VESA: v2.0, 4096k memory, flags:0x0, mode table:0xc037dec2 (122) VESA: ATI MACH64 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX ATA controller port 0xff90-0xff9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ahc0: Adaptec 2940 Ultra SCSI adapter port 0xf800-0xf8ff mem 0xffbee000-0xffbeefff irq 10 at device 13.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs pci0: display, VGA at device 14.0 (no driver attached) atapci1: Promise ATA66 controller port 0xff00-0xff3f,0xffe0-0xffe3,0xffa8-0xffaf,0xffe4-0xffe7,0xfff0-0xfff7 mem 0xffbc-0xffbd irq 11 at device 15.0 on pci0 ata2: at 0xfff0 on atapci1 ata3: at 0xffa8 on atapci1 orm0: Option ROMs at iomem 0xed000-0xedfff,0xca000-0xca7ff,0xc8000-0xc9fff,0xc-0xc7fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ed0 at port 0x300-0x31f iomem 0xd8000 irq 5 on isa0 ed0: address 00:80:c8:37:e2:a6, type NE2000 (16 bit) fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sc0: System console at flags 0x100 on isa0 sc0: VGA 5 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0401 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0501 can't assign resources (port) Timecounters tick every 1.000 msec ata0-slave: ATAPI identify retries exceeded ad4: 2445MB QUANTUM FIREBALL EL2.5A [5300/15/63] at ata2-master UDMA33 ad6: 2423MB SAMSUNG WU32553A (2.54GB) [4924/16/63] at ata3-master UDMA33 acd0: CDROM WPI CDD-820 at ata0-master PIO3 Waiting 15 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0
Re: -O2 considered harmful
On Fri, Feb 28, 2003 at 05:52:59PM -0800, Terry Lambert wrote: I have seen this as well, using -O2 -march=athlon-xp. The generated assembler tried to stuff -129 into a single byte. What about just trying -march=athlon? The only difference is the SSE support, which is quite new and may have latent bugs anyway. I didn't try that, but i did not get that error using: -O2 -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse to compile the xc/ tree Is it just me, or does this whole discussion boil down to something like How can I overclock my compiler?? I'd say it's more something like How can I get my money's worth out of my processor? With modern processors having multiple functional units, capable of queuing and executing multiple instructions simultaneously, we need some way to take advantage of this - so that we use 100% of the CPU instead of 75%. So, for example using the new SSE functional unit instead of the aged hacked 387 makes sense, hence the -mfpmath=sse flag. I have just recompiled the world and all my ports using -O2 -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse and everything except ezm3 compiled cleanly (adding -fno-schedule-insns2 to the flags made it compile). Mozilla doesn't crash any more. Bruce Cran To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wi0 - need help
On Sat, Mar 01, 2003 at 11:35:37AM -0700, M. Warner Losh wrote: Not sure whether I group replied, so maybe you will be receiving two similar sounding answers, Warner. In message: [EMAIL PROTECTED] Christoph P. Kukulies [EMAIL PROTECTED] writes: : Warner, I applied the patch and no change. marcel's patch, or my patch? Both's have been applied. The driver is patched twice. : How does one specify the commands in the ifconfig interface? : This is what I used to invoke from /etc/rc.local: : : /usr/sbin/wicontrol -i wi0 -n kuku : /usr/sbin/wicontrol -i wi0 -p 1 : /usr/sbin/wicontrol -i wi0 -c 1 : /usr/sbin/wicontrol -i wi0 -s bgate : ifconfig wi0 192.168.254.1 netmask 255.255.255.0 (assuming that you are using a real access point, or a freebsd server in hostap mode): ifconfig wi0 192.168.254.1 netmask 255.255.255.0 ssid kuku stationname \ bgate media DS/11Mbps If you are trying to do a IBSS network, and are running 5.x, you'd want to do something like: ifconfig wi0 192.168.254.1 netmask 255.255.255.0 ssid kuku stationname \ bgate media DS/11Mbps mediaopt adhoc [*] It works! Packets started flowing right after I typed in the above line. and ifconfig wi0 192.168.254.2 netmask 255.255.255.0 ssid kuku stationname \ kukulap media DS/11Mbps mediaopt adhoc[*] [*] adhoc is spelled ibss-create on 4.x Warner How can I find out whether I can run the interface in hostap mode? At the moment it runs in adhoc mode. -- 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: wi0 - need help
On Sat, Mar 01, 2003 at 08:08:36PM +0100, Christoph P. Kukulies wrote: On Sat, Mar 01, 2003 at 11:35:37AM -0700, M. Warner Losh wrote: It works! Packets started flowing right after I typed in the above line. and ifconfig wi0 192.168.254.2 netmask 255.255.255.0 ssid kuku stationname \ kukulap media DS/11Mbps mediaopt adhoc[*] [*] adhoc is spelled ibss-create on 4.x Warner How can I find out whether I can run the interface in hostap mode? At the moment it runs in adhoc mode. If you try ifconfig bla hostap and the card is not capable of doing that (wrong chipset e.g) it will give you an error. Wilko -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wi0 - need help
On Sat, Mar 01, 2003 at 06:08:27AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : status: no carrier : ssid 1: : : Did you do `wicontrol -i wi0 -p 1'? I've found that the new driver really really really hates the old wicontrol interface when the commands are also present in the ifconfig interface. Ah, ok. I still use wicontrol for WiFi specific things and leave the IP related stuff to ifconfig. BTW: Shouldn't we obsolete wicontrol then or strip functionality? It appears we have 2 ways in which we can do things now... -- 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: wi0 - need help
In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : BTW: Shouldn't we obsolete wicontrol then or strip functionality? : It appears we have 2 ways in which we can do things now... I'm planning on doing that soonish. However, I think that hacking wi to make it work for lucent and symbol cards again takes precedence. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
TI WiFi Drivers
Does anyone know if someone is working on WiFi drivers for cards based on the TI chipset running at 22Mbps (ie. D-link DWL-650+ pcmcia 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: wi0 - need help
On Sat, Mar 01, 2003 at 12:23:22PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Marcel Moolenaar [EMAIL PROTECTED] writes: : BTW: Shouldn't we obsolete wicontrol then or strip functionality? : It appears we have 2 ways in which we can do things now... I'm planning on doing that soonish. However, I think that hacking wi to make it work for lucent and symbol cards again takes precedence. Definitely. I just didn't know it was tagged with a todo label already. 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
kernel panic
With my three days old 5.0-current I had a kernel panic this afternoon while I had wi0 in promiscous mode (FWIW). Message was: panic: headlocked should be 0 -- 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: Sound problem: ac97 codec invalid or not present
Hugo Having 'device pcm' in the kernel is all you should need for you VT82C686 (kldload'ing sound drivers requires pcm support not be compiled into the kernel. The are two portions to the sound h/w you have, the pcm component, ie the VT82C686, and the AC97 codec that controls the mixer and routing of the audio within the h/w. The AC97 code does not detect your AC97 codec so you end up with a pcm component with no ac97 mixer. Does you BIOS have an onboard sound setting? If this is not enabled then might explain what you see. Failing that can you post the complete output of dmesg and set 'sysctl hw.snd.verbose=3' and post the output of 'cat '/dev/sndstat'? Thanks - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
old serial RS-232 pccard and wi driver.
Hello, I encounter a strange problem with an old rs-232 serial pccard on current (just cvsup'ed). The card works quite well on 5.0-RELEASE, but it it is detected as a wlan card on current, and the system attempts to run the wi driver. This calls ther debugger, and the (continue) command reboot the machine, and that at boot, or after any card insertion. I don't know if the machine is very relevant but ... DELL Inspiron 8000 laptop.. The acpi is loaded, and seems to work. An Adaptec apa-1460 pccard works well too, (the IRQ (11) is correctly handled). Here is the message at boot: pccard1: CIS checksum failed. wi0: Socket Communications Low Power wlan card at port 0x100-0x107 irq 11= fun1 wi0 init failed. panic block: (sleep mutex wi0 not locked @ /usr/src-current/src/sys/devwi/= if_w3 debugger (panic) stopped at: debugger+0x54: xchgl %ebx,in_debugger.0. Sorry if I have forgotten something. Best regards raoul [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
Juli Mallett wrote: * De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ] [ Subjecte: Re: PATCH: type errors in src-tree ] Sorry for resending (3rd time), but I've found a small typo in the patch of sbin/atm/ilmid/ilmid.c - u_char **bufp; - Objid *objid; + caddr_t *bufp; + Objid *objid; I understand (and think good catch) on a number of other things, and bogus type-width assumptions being caught, etc. But this? caddr_t considered useless. Maybe you could clarify why you made the changes to use caddr_t? 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 *'. Thanx, juli. Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic
Date: Sat, 1 Mar 2003 With my three days old 5.0-current panic: headlocked should be 0 Try updating to rev 1.198 of tcp_input.c which was committed on Feb 26, around 3 days ago. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Juli Mallett wrote:
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
caddr_t is discouraged, with preference of writing an actual type. caddr_t
is just an obfuscation. I'm unclear what it gains in your context.
Okay, sorry for misusing caddr_t. Here's a patch without any caddr_t,
but with 'char *' and 'const char *'.
Let me know what you're thinking about it.
Jens
--- sbin/atm/ilmid/ilmid.c.orig Wed Jan 1 18:48:45 2003
+++ sbin/atm/ilmid/ilmid.c Sat Mar 1 23:31:29 2003
@@ -162,7 +162,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +173,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +185,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -279,7 +279,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -292,7 +292,7 @@
* TRAP generic trap types
*/
char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +320,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,7 +338,7 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
+void set_reqid( char *, uint32_t );
void Increment_DL( int );
void Decrement_DL( int );
@@ -376,7 +379,7 @@
/*
* Utility to pretty print buffer as hex dumps
- *
+ *
* Arguments:
* bp - buffer pointer
* len - length to pretty print
@@ -387,10 +390,10 @@
*/
void
hexdump ( bp, len )
- u_char *bp;
- int len;
+ const char *bp;
+ const uint32_t len;
{
- int i, j;
+ uint32_ti, j;
/*
* Print as 4 groups of four bytes. Each byte is separated
@@ -443,7 +446,7 @@
* bufp- pointer to buffer pointer
* plen- pointer to PDU length or NULL if not a concern
*
- * Returns:
+ * Returns:
* bufp- updated buffer pointer
* plen- (possibly) adjusted pdu length
* len - decoded length
@@ -451,21 +454,21 @@
*/
int
asn_get_pdu_len ( bufp, plen )
- u_char **bufp;
- int *plen;
+ const char ** const bufp;
+ uint32_t* const plen;
{
- u_char *bp = *bufp;
- int len = 0;
- int i, b;
+ const char *bp =*bufp;
+ uint32_tlen = 0;
+ uint32_ti, b;
b = *bp++;
if ( plen )
- (*plen)--;
-if ( b 0x80 ) {
- for ( i = 0; i (b ~0x80); i++ ) {
+ --(*plen);
+ if ( b 0x80 ) {
+ for ( i = 0; i (b ~0x80); ++i ) {
len = len * 256 + *bp++;
if ( plen )
- (*plen)--;
+ --(*plen);
}
} else
len = b;
@@ -492,12 +495,12 @@
*/
int
asn_get_encoded ( bufp, len )
- u_char **bufp;
- int *len;
+ const char ** const bufp;
+ uint32_t* const len;
{
- u_char *bp = *bufp;
- int val = 0;
- int l = *len;
+ const char *bp = *bufp;
+ int val = 0; /* FIXME: signed? sure? */
+ uint32_tl = *len;
/*
* Keep going while high bit is set
@@ -507,7 +510,7 @@
* Each byte can represent 7 bits
*/
val = ( val 7 ) + ( *bp ~0x80 );
- l--;
+
Re: PATCH: type errors in src-tree
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote: ... - u_char **bufp; + caddr_t *bufp; ... 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 *'. Shouldn't we care about u_char vs char? On some machines it matters, and on all machines compilers tend to notice and generate warnings. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters,
and on all machines compilers tend to notice and generate warnings.
Yes, usually we should. But I reviewed the code and didn't found a
reason for using 'unsigned char'. I got compiler warning ('couse I have
them enabled all) during compiling the file before I have finished the
patch. But most of the code relies on 'char' and 'u_char' was used for
storing chars only. Do you know any machine which stores signed chars
different than unsigned chars?
But the mixing - which was in it before - was not acceptable.
Jens
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Barney Wolff wrote: On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote: Shouldn't we care about u_char vs char? On some machines it matters, and on all machines compilers tend to notice and generate warnings. Just another question: I turned on '-ansi' and got some warning about a function declaration is not a prototype (all functions are declared in KR style). Is it preferred by the FreeBSD-Team having functions in KR styles or is the Ansi-Style on, too? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ] [ Subjecte: Re: PATCH: type errors in src-tree ] Barney Wolff wrote: On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote: Shouldn't we care about u_char vs char? On some machines it matters, and on all machines compilers tend to notice and generate warnings. Just another question: I turned on '-ansi' and got some warning about a function declaration is not a prototype (all functions are declared in KR style). Is it preferred by the FreeBSD-Team having functions in KR styles or is the Ansi-Style on, too? ANSI is preferred, but mixing style with functional changes is discouraged. I get the impression your change to width-specified values has a real correlation to what things need to use, and thus it might fix brokenness with systems not ILP32. 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
Re: TI WiFi Drivers
In message: [EMAIL PROTECTED] Suneel Jhangiani [EMAIL PROTECTED] writes: : Does anyone know if someone is working on WiFi drivers for cards based : on the TI chipset running at 22Mbps (ie. D-link DWL-650+ pcmcia card)? 22Mbps isn't WiFi. It is Ti's own proprietary thing that 802.11g rejected. However, the chips used in the DWL-650+ card aren't documented. Or the docs aren't available, even with an NDA last time I checked :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Juli Mallett wrote:
* De: Jens Rehsack [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Re: PATCH: type errors in src-tree ]
Barney Wolff wrote:
On Sat, Mar 01, 2003 at 11:09:03PM +0100, Jens Rehsack wrote:
Shouldn't we care about u_char vs char? On some machines it matters,
and on all machines compilers tend to notice and generate warnings.
Just another question: I turned on '-ansi' and got some warning about a
function declaration is not a prototype (all functions are declared in
KR style). Is it preferred by the FreeBSD-Team having functions in KR
styles or is the Ansi-Style on, too?
ANSI is preferred, but mixing style with functional changes is discouraged.
I get the impression your change to width-specified values has a real
correlation to what things need to use, and thus it might fix brokenness
with systems not ILP32.
Ok, patch which complete ansi declarations appended. This fixes
enumerous errors with 'declaration is not a prototype' messages.
Thanx,
juli.
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
--- sbin/atm/ilmid/ilmid.c.orig Sun Mar 2 00:30:57 2003
+++ sbin/atm/ilmid/ilmid.c Sun Mar 2 00:50:40 2003
@@ -92,7 +92,8 @@
#defineASN_IPADDR 0x40
#defineASN_TIMESTAMP 0x43
-static char *Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET, ASN_NULL,
ASN_OBJID };
+static const char * const Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET,
+ ASN_NULL, ASN_OBJID };
/*
* Define SNMP PDU types
@@ -103,8 +104,8 @@
#definePDU_TYPE_SET0xA3
#definePDU_TYPE_TRAP 0xA4
-static char *PDU_Types[] = { GET REQUEST, GETNEXT REQUEST, GET RESPONSE, SET
REQUEST,
- TRAP };
+static const char * const PDU_Types[] = { GET REQUEST, GETNEXT REQUEST,
+ GET RESPONSE, SET REQUEST, TRAP };
/*
* Define TRAP codes
@@ -162,7 +163,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +174,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +186,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -210,7 +211,7 @@
* foresiggrp: FORE specific Objid we see alot of (being connected to FORE
* switches...)
*/
-Objid Objids[] = {
+const ObjidObjids[] = {
#defineSYS_OBJID 0
{{ 8, 43, 6, 1, 2, 1, 1, 2, 0 }},
#defineUPTIME_OBJID1
@@ -279,7 +280,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -291,8 +292,8 @@
/*
* TRAP generic trap types
*/
-char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+const char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +321,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,11 +339,11 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
-void Increment_DL( int );
-void Decrement_DL( int );
+static voidset_reqid( char *, uint32_t );
+static voidIncrement_DL( int );
+static voidDecrement_DL( int );
-static char
Re: PATCH: type errors in src-tree
Juli Mallett wrote:
ANSI is preferred, but mixing style with functional changes is discouraged.
I get the impression your change to width-specified values has a real
correlation to what things need to use, and thus it might fix brokenness
with systems not ILP32.
Sorry, it's getting late here - seems that the compiler didn't cast
itself to 'char const **' in line 2279.
Jens
--
L i W W W i Jens Rehsack
LW W W
L i W W W W i nnnLiWing IT-Services
L iW W W Wi n n g g
i W W i n n g gFriesenstraße 2
06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED]
Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/
--- sbin/atm/ilmid/ilmid.c.orig Sun Mar 2 00:30:57 2003
+++ sbin/atm/ilmid/ilmid.c Sun Mar 2 00:56:16 2003
@@ -92,7 +92,8 @@
#defineASN_IPADDR 0x40
#defineASN_TIMESTAMP 0x43
-static char *Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET, ASN_NULL,
ASN_OBJID };
+static const char * const Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET,
+ ASN_NULL, ASN_OBJID };
/*
* Define SNMP PDU types
@@ -103,8 +104,8 @@
#definePDU_TYPE_SET0xA3
#definePDU_TYPE_TRAP 0xA4
-static char *PDU_Types[] = { GET REQUEST, GETNEXT REQUEST, GET RESPONSE, SET
REQUEST,
- TRAP };
+static const char * const PDU_Types[] = { GET REQUEST, GETNEXT REQUEST,
+ GET RESPONSE, SET REQUEST, TRAP };
/*
* Define TRAP codes
@@ -162,7 +163,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +174,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +186,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -210,7 +211,7 @@
* foresiggrp: FORE specific Objid we see alot of (being connected to FORE
* switches...)
*/
-Objid Objids[] = {
+const ObjidObjids[] = {
#defineSYS_OBJID 0
{{ 8, 43, 6, 1, 2, 1, 1, 2, 0 }},
#defineUPTIME_OBJID1
@@ -279,7 +280,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -291,8 +292,8 @@
/*
* TRAP generic trap types
*/
-char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+const char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +321,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,11 +339,11 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
-void Increment_DL( int );
-void Decrement_DL( int );
+static voidset_reqid( char *, uint32_t );
+static voidIncrement_DL( int );
+static voidDecrement_DL( int );
-static char*Months[] = { Jan, Feb, Mar, Apr, May, Jun,
+static const char *Months[] = { Jan, Feb, Mar, Apr, May, Jun,
Jul, Aug, Sep, Oct, Nov, Dec };
/*
@@ -355,14 +359,14 @@
* none
*
*/
-void
-write_timestamp()
+static void
+write_timestamp(void)
{
- time_t clock;
+ time_t cur_clock;
struct tm *tm;
- clock = time ( (time_t)NULL );
- tm = localtime ( clock );
+ cur_clock = time ( (time_t)NULL );
+ tm = localtime ( cur_clock );
if ( Log Debug_Level 1 )
if ( Log != stderr )
@@ -385,12
Re: PATCH: type errors in src-tree
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
- u_char *resp;
+static void
+send_resp ( const int intf, Snmp_Header *Hdr, char *resp )
{
int n;
- if ( ilmi_fd[intf] 0 ) {
- n = write ( ilmi_fd[intf], (caddr_t)resp[1], resp[0] );
+ if ( ilmi_fd[intf] 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range?
*/
+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
...
Here's a case where it matters whether something is u_char or char.
write(2) takes a size_t as its third arg, and extension of a char to
that may not be the same as for u_char, for example on Sparc. If the
response is ever 127 bytes, this will fail. You're going to have to
look carefully at how things are used to see when char is appropriate
and when u_char is necessary.
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Barney Wolff wrote:
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
- u_char *resp;
+static void
+send_resp ( const int intf, Snmp_Header *Hdr, char *resp )
{
int n;
- if ( ilmi_fd[intf] 0 ) {
- n = write ( ilmi_fd[intf], (caddr_t)resp[1], resp[0] );
+ if ( ilmi_fd[intf] 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range?
*/
+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
...
Here's a case where it matters whether something is u_char or char.
write(2) takes a size_t as its third arg, and extension of a char to
that may not be the same as for u_char, for example on Sparc. If the
response is ever 127 bytes, this will fail. You're going to have to
look carefully at how things are used to see when char is appropriate
and when u_char is necessary.
That is really right, but for those check I have to know more 'bout ATM,
right? I just have detected some compiler errors using
-finline-functions (yes, I'm playing with optimization options :-)). If
you know a real good online-reference, one fine day I'll check it and
check the entire ilmid.c code for valid signment.
Jens
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: type errors in src-tree
Barney Wolff wrote:
This is an example of what I was pointing out:
On Sun, Mar 02, 2003 at 01:53:33AM +0100, Jens Rehsack wrote:
...
@@ -1444,22 +1420,19 @@
* none- response sent
*
*/
-void
-send_resp ( intf, Hdr, resp )
- int intf;
- Snmp_Header *Hdr;
- u_char *resp;
+static void
+send_resp ( const int intf, Snmp_Header *Hdr, char *resp )
{
int n;
- if ( ilmi_fd[intf] 0 ) {
- n = write ( ilmi_fd[intf], (caddr_t)resp[1], resp[0] );
+ if ( ilmi_fd[intf] 0 ) { /* FIXME: does ilmi_fd[intf] exists? out of range?
*/
+ n = write ( ilmi_fd[intf], resp+1, resp[0] );
...
Here's a case where it matters whether something is u_char or char.
write(2) takes a size_t as its third arg, and extension of a char to
that may not be the same as for u_char, for example on Sparc. If the
response is ever 127 bytes, this will fail. You're going to have to
look carefully at how things are used to see when char is appropriate
and when u_char is necessary.
Fixed, thanks.
Jens
--- sbin/atm/ilmid/ilmid.c.orig Sun Mar 2 00:30:57 2003
+++ sbin/atm/ilmid/ilmid.c Sun Mar 2 01:45:06 2003
@@ -92,7 +92,8 @@
#defineASN_IPADDR 0x40
#defineASN_TIMESTAMP 0x43
-static char *Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET, ASN_NULL,
ASN_OBJID };
+static const char * const Var_Types[] = { , , ASN_INTEGER, , ASN_OCTET,
+ ASN_NULL, ASN_OBJID };
/*
* Define SNMP PDU types
@@ -103,8 +104,8 @@
#definePDU_TYPE_SET0xA3
#definePDU_TYPE_TRAP 0xA4
-static char *PDU_Types[] = { GET REQUEST, GETNEXT REQUEST, GET RESPONSE, SET
REQUEST,
- TRAP };
+static const char * const PDU_Types[] = { GET REQUEST, GETNEXT REQUEST,
+ GET RESPONSE, SET REQUEST, TRAP };
/*
* Define TRAP codes
@@ -162,7 +163,7 @@
union {
int ival; /* INTEGER/TIMESTAMP */
Objid oval; /* OBJID */
- longaval; /* IPADDR */
+ uint32_taval; /* IPADDR */
charsval[STRLEN]; /* OCTET */
} var;
Variable*next;
@@ -173,10 +174,10 @@
* which doesn't have the last three fields is the TRAP type.
*/
struct snmp_header {
- int pdulen;
- int version;
+ uint32_tpdulen;
+ uint32_tversion;
charcommunity[64];
- int pdutype;
+ uint32_tpdutype;
/* GET/GETNEXT/GETRESP/SET */
int reqid;
@@ -185,11 +186,11 @@
/* TRAP */
Objid enterprise;
- int ipaddr;
+ uint32_tipaddr;
int generic_trap;
int specific_trap;
- int varlen;
+ uint32_tvarlen;
Variable*head,
*tail;
};
@@ -210,7 +211,7 @@
* foresiggrp: FORE specific Objid we see alot of (being connected to FORE
* switches...)
*/
-Objid Objids[] = {
+const ObjidObjids[] = {
#defineSYS_OBJID 0
{{ 8, 43, 6, 1, 2, 1, 1, 2, 0 }},
#defineUPTIME_OBJID1
@@ -279,7 +280,7 @@
* Temporary buffer for building response packets. Should help ensure
* that we aren't accidently overwriting some other memory.
*/
-u_char Resp_Buf[1024];
+char Resp_Buf[1024];
/*
* Copy the reponse into a buffer we can modify without
@@ -291,8 +292,8 @@
/*
* TRAP generic trap types
*/
-char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
- authenticationFailure, egpNeighborLoss,
+const char *Traps[] = { coldStart, warmStart, linkDown, linkUp,
+ authenticationFailure, egpNeighborLoss,
enterpriseSpecific };
@@ -320,6 +321,9 @@
*/
Objid addressEntry[MAX_UNITS + 1];
+static const char ilmi_ident_str[] = ILMI;
+static const size_tilmi_ident_str_len = strlen(ILMI);
+
/*
* When this daemon started
*/
@@ -335,11 +339,11 @@
#defineLOG_FILE/var/log/ilmid
FILE *Log; /* File descriptor for log messages */
-void set_reqid( u_char *, int );
-void Increment_DL( int );
-void Decrement_DL( int );
+static voidset_reqid( char *, uint32_t );
+static voidIncrement_DL( int );
+static voidDecrement_DL( int );
-static char*Months[] = { Jan, Feb, Mar, Apr, May, Jun,
+static const char *Months[] = { Jan, Feb, Mar, Apr, May, Jun,
Jul, Aug, Sep, Oct, Nov, Dec };
/*
@@ -355,14 +359,14 @@
* none
*
*/
-void
-write_timestamp()
+static void
+write_timestamp(void)
{
- time_t clock;
+ time_t cur_clock;
struct tm *tm;
- clock = time ( (time_t)NULL );
-
Re: PATCH: type errors in src-tree
On Sun, Mar 02, 2003 at 02:33:55AM +0100, Jens Rehsack wrote: ... + n = write ( ilmi_fd[intf], resp+1, resp[0] ); Here's a case where it matters whether something is u_char or char. write(2) takes a size_t as its third arg, and extension of a char to that may not be the same as for u_char, for example on Sparc. If the response is ever 127 bytes, this will fail. You're going to have to look carefully at how things are used to see when char is appropriate and when u_char is necessary. That is really right, but for those check I have to know more 'bout ATM, right? I just have detected some compiler errors using -finline-functions (yes, I'm playing with optimization options :-)). If you know a real good online-reference, one fine day I'll check it and check the entire ilmid.c code for valid signment. This has nothing to do with ATM. It has to do with how the code that's in the file uses 8-bit bytes, and how it calls standard functions. If you make changes blindly just to get rid of compiler warnings, you will introduce bugs in operation that may be difficult to find, years later. The fact that Resp_Buf needs to remain a u_char[] is just one example. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Possible patch for limiting APs at startup
Hello. Just as the topic says, do you think this patch is good enough, or gets even close to it? I have tested the patch, and it seems to do it's job in the right way. Some might call it hackery, but it's better than nothing I would suppose. Before: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 ... Launch AP CPUs etc ... After: boot-prompt set machdep.smp_cpus=0 boot-prompt boot -sv FreeBSD/SMP: Multiprocessor System Detected: 1 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 Patch attached with mail. Cheers. P.S. One more question, there are some extern variables in the i386/include/smp.h header file, and I don't think they are used anywhere in an extern way... can comment on patch available at the following location: http://www.unixdaemons.com/~hiten/work/diffs/eremove.patch -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ Index: sys/i386/i386/mp_machdep.c === RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v retrieving revision 1.203 diff -u -r1.203 mp_machdep.c --- sys/i386/i386/mp_machdep.c 24 Feb 2003 14:36:03 - 1.203 +++ sys/i386/i386/mp_machdep.c 2 Mar 2003 01:25:10 - @@ -278,6 +278,9 @@ int io_num_to_apic_id[NAPICID]; int apic_id_to_logical[NAPICID]; +TUNABLE_INT(machdep.smp_cpus, (int *)mp_naps); +SYSCTL_INT(_machdep, OID_AUTO, smp_cpus, CTLFLAG_RD, +mp_naps, 1, Number of Application processors in use.); /* AP uses this during bootstrap. Do not staticize. */ char *bootSTK;
Re: Possible patch for limiting APs at startup
* De: Hiten Pandya [EMAIL PROTECTED] [ Data: 2003-03-01 ]
[ Subjecte: Possible patch for limiting APs at startup ]
Hello.
Just as the topic says, do you think this patch is good enough, or gets
even close to it? I have tested the patch, and it seems to do it's job
in the right way. Some might call it hackery, but it's better than
nothing I would suppose.
I think your use of cpus to refer to APs only is silly, and also that
overriding mp_naps instead of using a real cpus value and using it as
a bounds check akin to MAXCPU, is a bit of the wrong direction. As you
know, the following is my patch, and it does not work, but I think,
personally, the behaviour is saner, in theory at least :)
%%%
Index: mp_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v
retrieving revision 1.203
diff -d -c -r1.203 mp_machdep.c
*** mp_machdep.c24 Feb 2003 14:36:03 - 1.203
--- mp_machdep.c2 Mar 2003 00:22:58 -
***
*** 249,254
--- 249,259
/** XXX FIXME: what system files declare these??? */
extern struct region_descriptor r_gdt, r_idt;
+ int mp_maxcpus = 0; /* max CPUs; not in BSS so it can be hacked. */
+ TUNABLE_INT(machdep.smp_max_cpus, mp_maxcpus);
+ SYSCTL_INT(_machdep, OID_AUTO, smp_max_cpus, CTLFLAG_RD,
+ mp_maxcpus, 1, Maximum number of CPUs to use.);
+
int bsp_apic_ready = 0; /* flags useability of BSP apic */
int mp_naps;/* # of Applications processors */
int mp_nbusses; /* # of busses */
***
*** 864,874
}
}
! /* qualify the numbers */
! if (mp_naps MAXCPU) {
printf(Warning: only using %d of %d available CPUs!\n,
! MAXCPU, mp_naps);
! mp_naps = MAXCPU;
}
/* See if we need to fixup HT logical CPUs. */
--- 869,881
}
}
! /* use the smallest number of requested CPUs or CPUs we support. */
! if ((mp_maxcpus 0 mp_naps mp_maxcpus) || mp_naps MAXCPU) {
! if (mp_maxcpus = 0)
! mp_maxcpus = MAXCPU;
printf(Warning: only using %d of %d available CPUs!\n,
! mp_maxcpus, mp_naps);
! mp_naps = mp_maxcpus;
}
/* See if we need to fixup HT logical CPUs. */
%%%
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
Re: Any ideas why we can't even boot a i386 ?
Blue Lightning was an i486 core in a i386SX/DX compatible package (usually SX). AMD's i386DX's predate Blue Lightning by about 5 years. Adam - Original Message - From: Terry Lambert [EMAIL PROTECTED] To: Bob Bishop [EMAIL PROTECTED] Cc: M. Warner Losh [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 01, 2003 10:57 AM Subject: Re: Any ideas why we can't even boot a i386 ? Bob Bishop wrote: At 21:06 28/2/03, M. Warner Losh wrote: [...] We have some a few embedded systems coming back from the field soon and I plan on trying some tests on them (they are amd 386, so might not be good for you). [etc] IIRC AMD had a mask deal with Intel for the 386, so should be OK. Are you sure that AMD did not use the IBM Blue Lightening core? I'm pretty sure that there are a huge number of embedded controllers that used the Intel 386GX macrocell, though... -- Terry 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
distributed folding client panics -current
panic: bwrite: 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
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
#1 0xc01bc519 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2 0xc01bc783 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#3 0xc0200982 in bwrite (bp=0xc7838668) at /usr/src/sys/kern/vfs_bio.c:795
#4 0xc02023f9 in vfs_bio_awrite (bp=0xc7838668)
at /usr/src/sys/kern/vfs_bio.c:1689
#5 0xc0209daf in vop_stdfsync (ap=0xcd32d888)
at /usr/src/sys/kern/vfs_default.c:755
#6 0xc0180f50 in spec_fsync (ap=0xcd32d888)
at /usr/src/sys/fs/specfs/spec_vnops.c:422
#7 0xc0180428 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:123
#8 0xc026f487 in ffs_sync (mp=0xc25b9a00, waitfor=2, cred=0xc0eb5e80,
td=0xc0316840) at vnode_if.h:612
#9 0xc021720b in sync (td=0xc0316840, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#10 0xc01bc0fc in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280
#11 0xc01bc783 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
#12 0xc02c9c92 in trap_fatal (frame=0xcd32da50, eva=0)
at /usr/src/sys/i386/i386/trap.c:843
#13 0xc02c9972 in trap_pfault (frame=0xcd32da50, usermode=0, eva=32)
at /usr/src/sys/i386/i386/trap.c:757
#14 0xc02c9460 in trap (frame=
---Type return to continue, or q return to quit---
{tf_fs = -1058209768, tf_es = -852361200, tf_ds = -1071382512, tf_edi = -1
058255824, tf_esi = 0, tf_ebp = -852305228, tf_isp = -852305284, tf_ebx = -10704
44436, tf_edx = -1058255824, tf_ecx = -1014380816, tf_eax = 1, tf_trapno = 12, t
f_err = 0, tf_eip = -1071964106, tf_cs = 8, tf_eflags = 66050, tf_esp = 16, tf_s
s = -1071351664}) at /usr/src/sys/i386/i386/trap.c:444
#15 0xc02b95f8 in calltrap () at {standard input}:96
#16 0xc0242699 in tcp_input (m=0xc0ec4c30, off0=20)
at /usr/src/sys/netinet/tcp_input.c:2324
#17 0xc023bc56 in ip_input (m=0xc0ed7c00)
at /usr/src/sys/netinet/ip_input.c:947
#18 0xc023bd42 in ipintr () at /usr/src/sys/netinet/ip_input.c:965
#19 0xc022d713 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
#20 0xc01a8371 in ithread_loop (arg=0xc0ec2100)
at /usr/src/sys/kern/kern_intr.c:536
#21 0xc01a7263 in fork_exit (callout=0xc01a81a0 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:871
--
Without the userland, the kernel is useless.
--inspired by The Tao of Programming
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
why libkvm not implement read from user memory space
Hi All, 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. I found kgdb is not easy to use when checking a core dump. And hackers want users to collect the information regarding to the kernel panic. It is not easy to let everyone understand kernel structures. So I have implemented two new command in the kgdb to help users checking coredump. One is kldstat, the other is ps. Anyone interesing this? or you think these functions are no use. Please let me know your option. Thanks. -Jun Su Newbie in Freebsd. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
