RE: 5.1-RELEASE TODO
Larry, Did you ever get back to Intel's Robert Moore WRT to his May 21st message (Msg-ID [EMAIL PROTECTED]) ? Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Thu, 5 Jun 2003, Larry Rosenman wrote: --On Thursday, June 05, 2003 18:59:49 +0200 Erik Paulsen Skaalerud [EMAIL PROTECTED] wrote: FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. LER ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.1-RELEASE TODO
Yes I did, and NO replies (at least directly to me). he was CC'd on a NUMBER of replies from me to both Nate and others. LER --On Tuesday, June 10, 2003 07:59:12 -0400 Andre Guibert de Bruet [EMAIL PROTECTED] wrote: Larry, Did you ever get back to Intel's Robert Moore WRT to his May 21st message (Msg-ID [EMAIL PROTECTED]) ? Regards, Andre Guibert de Bruet | Enterprise Software Consultant Silicon Landmark, LLC. | http://siliconlandmark.com/ On Thu, 5 Jun 2003, Larry Rosenman wrote: --On Thursday, June 05, 2003 18:59:49 +0200 Erik Paulsen Skaalerud [EMAIL PROTECTED] wrote: FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. LER ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Tom Samplonius [EMAIL PROTECTED] writes: I guess I'm not the only one with hardware that is unusable with FreeBSD 5.x, but FreeBSD 5.x simply is not installable on Dell PowerEdge 6350 servers. FreeBSD 4.8 works fine on the same hardware. FreeBSD 5.0, 5.1-BETA1, 5.1-BETA2, and 5.1-RC1 all die in sysinstall is detecting hardware and drop the machine into the kernel debugger. It also kills the display, making it tough to catch. I've tried with ACPI off. Same result. What chipset does this machine use? I've recently seen similar problems on a friend's i810-based Toshiba Equium 3100M - with 4.7, 5.1, and some unknown incarnation of RedHat. I tried upgrading the BIOS and resetting it to safe defaults on the off chance that it was some kind of power management bug, to no avail. Immediately after sysinstall comes up and starts probing devices, the display goes blank, but the machine doesn't shut down - the PSU fan, CD-ROM and harddisk keep spinning. I can't remember whether the CPU fan stopped. Unfortunately, I didn't have a serial console available. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On 07-Jun-2003 Tom Samplonius wrote: I guess I'm not the only one with hardware that is unusable with FreeBSD 5.x, but FreeBSD 5.x simply is not installable on Dell PowerEdge 6350 servers. FreeBSD 4.8 works fine on the same hardware. FreeBSD 5.0, 5.1-BETA1, 5.1-BETA2, and 5.1-RC1 all die in sysinstall is detecting hardware and drop the machine into the kernel debugger. It also kills the display, making it tough to catch. I've tried with ACPI off. Same result. I've submitted a PR (#52561), about this problem. I've updated it recently as I now know the exact point it dies. Since FreeBSD is also killing the video display, it was initially hard to see. Is there is any more information that anyone needs? I wanted to use 5.1-RELEASE on these machines, but I assume now that 5.1-RELEASE will have this bug too. Can you hook up a serial console and try again? When the loader does the 10 second countdown, hit space and type 'set console=comconsole'. This will give you a 9600N81 console on COM1 (sio0). Type 'boot' at the OK prompt and you should be able to get the panic mesage. If you can boot a kernel with ddb and get a trace that would be most helpful. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Mon, 9 Jun 2003, Dag-Erling Smorgrav wrote: Tom Samplonius [EMAIL PROTECTED] writes: I guess I'm not the only one with hardware that is unusable with FreeBSD 5.x, but FreeBSD 5.x simply is not installable on Dell PowerEdge 6350 servers. FreeBSD 4.8 works fine on the same hardware. FreeBSD 5.0, 5.1-BETA1, 5.1-BETA2, and 5.1-RC1 all die in sysinstall is detecting hardware and drop the machine into the kernel debugger. It also kills the display, making it tough to catch. I've tried with ACPI off. Same result. What chipset does this machine use? I'm not sure. FreeBSD 4.8 does work on the machine, and I posted the 4.8 dmesg into the PR (#52561). There aren't too many quad Xeon chipsets... probably Intel or Serverworks. I've recently seen similar problems on a friend's i810-based Toshiba Equium 3100M - with 4.7, 5.1, and some unknown incarnation of RedHat. I tried upgrading the BIOS and resetting it to safe defaults on the off chance that it was some kind of power management bug, to no avail. Immediately after sysinstall comes up and starts probing devices, the display goes blank, but the machine doesn't shut down - the PSU fan, CD-ROM and harddisk keep spinning. I can't remember whether the CPU fan stopped. Unfortunately, I didn't have a serial console available. I've tried serial console as well (with 5.1-RC1), and it just stops after probing the disks. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Mon, 9 Jun 2003, John Baldwin wrote: I've submitted a PR (#52561), about this problem. I've updated it ... Can you hook up a serial console and try again? When the loader does the 10 second countdown, hit space and type 'set console=comconsole'. This will give you a 9600N81 console on COM1 (sio0). Type 'boot' at the OK prompt and you should be able to get the panic mesage. If you can boot a kernel with ddb and get a trace that would be most helpful. I've tried this with 5.1-RC1, and nothing happened. Their were simply no more kernel messages after probing the amrd device. The machine appears to hang, and the video disply still turns off. I will try with 5.1-BETA2, since I believe that build has full debugging compiled in. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Thu, 5 Jun 2003, Robert Watson wrote: This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: Well, we won't be needing *that* anymore :-). Expect the 5.2 TODO to trickle in every few weeks for the next few months, and feel free to submit updates to the TODO list to [EMAIL PROTECTED] I should say, of course, that the primary goals for 5.2 are not new software features (although those will happen too), but improved performance, robustness, and usability across all of our platforms, so don't submit too many feature TODO items that will distract people from making that happen :-). I think I speak for everyone when I say I'm on the edge of my seat for RELENG_5 being branched--5.x has been a long time coming, but it's going to be well worth it. Thanks again to everyone who made the 5.1 release process happen, especially to those who spent the last couple of weeks chasing down obscure and difficult bugs (the ones that make such a difference); and to those who made the push to make libthr and libkse so much more functional. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Robert Watson wrote: | |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: 5.1-RELEASE TODO
Lars Eggert wrote: Robert Watson wrote: | |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.1-RELEASE TODO
FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 5.1-RELEASE TODO
--On Thursday, June 05, 2003 18:59:49 +0200 Erik Paulsen Skaalerud [EMAIL PROTECTED] wrote: FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. LER ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Larry Rosenman wrote: --On Thursday, June 05, 2003 18:59:49 +0200 Erik Paulsen Skaalerud [EMAIL PROTECTED] wrote: FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Lars Yeah, ACPI is causing many problems these days, much of which can be traced back to non-compliant system BIOS's. The new bootloader menu in FreeBSD 5.1 allows one to disable ACPI for the time being. Scott Will this lead to an extension of the release schedule for 5.1 until most of the problems are fixed? To me it looks like there are more and more reports about panics every day :( Erik For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. LER The official position is that ACPI is in a transition period right now, and that while that gets worked out we encourage people to disable it on their systems if they are not in a position to actively debug and fix it. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2332] Re: 5.1-RELEASE TODO
On Thu, 5 Jun 2003, Scott Long wrote: Larry Rosenman wrote: For the record, yesterday's sources STILL produce the panic at 0x7 for me on transition to battery. I can get more crashdumps/kernels if someone asks. I've mentioned this for the last ~1.5 months. The official position is that ACPI is in a transition period right now, and that while that gets worked out we encourage people to disable it on their systems if they are not in a position to actively debug and fix it. For those who find they may need to disable acpi, you can selectively disable different components. Larry, since yours is on battery transition, try debug.acpi.disable.ec=1 or possibly one of the other options. I recall that you had a thermal problem also. For Paul, who was having irq probing issues, try hw.acpi.pci.link.%d.%d.%d.irq to set it explicitly while leaving ACPI enabled. http://www.freebsd.org/cgi/man.cgi?query=acpiapropos=0sektion=0manpath=FreeBSD+5.0-currentformat=html I have been working on Campi's and LER's problems. But I only do this in my free time. Your best bet is acpi-jp@ as the Intel people are very good at this. Several other BSD users have been stepping up to help on that list and they are very much appreciated. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Lars Eggert writes: Robert Watson wrote: | |---++---+-- -| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+-- -| FYI, I still see the ACPI messages described in the Re: ACPI-0293 (and 0166) errors-thread on -current ca. 5/9/2003 on yesterday's -current. Also FYI. On my Shuttle AK35GTR (Version 1), when I turn on ACPI in the _latest_ BIOS version available I see something like: ffs_ufs: died with signal 8 on boot and the kernel then hangs. I _must_ turn off ACPI with FreeBSD, although it works with Windows XP. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
I guess I'm not the only one with hardware that is unusable with FreeBSD 5.x, but FreeBSD 5.x simply is not installable on Dell PowerEdge 6350 servers. FreeBSD 4.8 works fine on the same hardware. FreeBSD 5.0, 5.1-BETA1, 5.1-BETA2, and 5.1-RC1 all die in sysinstall is detecting hardware and drop the machine into the kernel debugger. It also kills the display, making it tough to catch. I've tried with ACPI off. Same result. I've submitted a PR (#52561), about this problem. I've updated it recently as I now know the exact point it dies. Since FreeBSD is also killing the video display, it was initially hard to see. Is there is any more information that anyone needs? I wanted to use 5.1-RELEASE on these machines, but I assume now that 5.1-RELEASE will have this bug too. Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Mon, 02 Jun 2003 07:09:44 -0300 Daniel C. Sobral [EMAIL PROTECTED] wrote: I hadn't any program running with legitimate access to /mnt and I have no program running which accesses a random filesystem path, so no vnodes should have been open then. Alas, lsof (ports) would be a better way of checking if there are vnodes open or not. I think fstat does that too, but I'm too used to lsof. Also, what is the error message? It was EBUSY. The first time I thought: sure, there's something open on it... with 3 xterms open where I use zsh as the shell it was easy to hunt for a program which I may have suspended, but I wasn't able to find one. Even umount -f wasn't able to umount the slice. As the disk was used to transport some data I wasn't able to look further into this. Now with a new kernel (from May 30) and another data transport on a harddisk I'm not able to reproduce the problem (a May 25 kernel failed to umount the slice). Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, Jun 01, 2003 at 03:00:09PM +0200, Bernd Walter wrote:
On Sun, Jun 01, 2003 at 02:26:34AM -0700, Luigi Rizzo wrote:
On Sun, Jun 01, 2003 at 03:32:56AM +0200, Bernd Walter wrote:
...
:)
And I hoped a programmer who knows the source could find out and fix
very quickly.
sorry, i missed the offending line number in your previous email.
I think i missed a in all the first arguments to bcopy in
the src/sbin/ipfw2.c changes :(
this happens at lines 818, 1224, 1461 and 1701. Fortunately
the kernel part seems correct.
In detail, the fix should be the following:
818:
- bcopy(rule-next_rule, set_disable, sizeof(set_disable));
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
1224:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
1461:
- bcopy(((struct ip_fw *)data)-next_rule,
+ bcopy(((struct ip_fw *)data)-next_rule,
1701:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
Look way bettter now :)
I wasn't able to crash the kernel with missaligned access any more, but
the userland tool still does in some situations:
[59]cicely12# ipfw show
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc
op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120003bdc ra=0x120003bc8
op=ldq
001005237 824333 allow tcp from any to any dst-port 1-65535,1-65535
00200 0 0 allow tcp from any to any dst-port 1-65535,1-65535,1-65535
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120002260 ra=0x1200015ec
op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120002264 ra=0x1200015ec
op=ldq
65535 5836817 1002036976 allow ip from any to any
I'm currently using the attached diff to ipfw2.c + your other changes.
It seems to work now.
I hope that I catched all missalignemts that were missing.
Thanks for the work on this.
I'm very happy to see this running on alpha.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
Index: ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.23
diff -u -r1.23 ipfw2.c
--- ipfw2.c 15 Mar 2003 01:12:59 - 1.23
+++ ipfw2.c 2 Jun 2003 13:22:30 -
@@ -348,6 +348,14 @@
{ NULL, 0 }
};
+static __inline u_int64_t
+align_uint64(u_int64_t *pll) {
+ u_int64_t ret;
+
+ bcopy (pll, ret, sizeof(ret));
+ return ret;
+};
+
/**
* match_token takes a table and a string, returns the value associated
* with the string (0 meaning an error in most cases)
@@ -813,8 +821,9 @@
int flags = 0; /* prerequisites */
ipfw_insn_log *logptr = NULL; /* set if we find an O_LOG */
int or_block = 0; /* we are in an or block */
+ u_int32_t set_disable;
- u_int32_t set_disable = rule-set_disable;
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
if (set_disable (1 rule-set)) { /* disabled */
if (!show_sets)
@@ -825,8 +834,8 @@
printf(%05u , rule-rulenum);
if (do_acct)
- printf(%*llu %*llu , pcwidth, rule-pcnt, bcwidth,
- rule-bcnt);
+ printf(%*llu %*llu , pcwidth, align_uint64(rule-pcnt),
+ bcwidth, align_uint64(rule-bcnt));
if (do_time) {
char timestr[30];
@@ -1213,13 +1222,16 @@
{
struct protoent *pe;
struct in_addr a;
+ uint16_t rulenum;
if (!do_expired) {
if (!d-expire !(d-dyn_type == O_LIMIT_PARENT))
return;
}
- printf(%05d %*llu %*llu (%ds), d-rulenum, pcwidth, d-pcnt, bcwidth,
+ bcopy(d-rule, rulenum, sizeof(rulenum));
+
+ printf(%05d %*llu %*llu (%ds), rulenum, pcwidth, d-pcnt, bcwidth,
d-bcnt, d-expire);
switch (d-dyn_type) {
case O_LIMIT_PARENT:
@@ -1454,7 +1466,9 @@
err(EX_OSERR, malloc);
if (getsockopt(s, IPPROTO_IP, IP_FW_GET, data, nbytes) 0)
err(EX_OSERR, getsockopt(IP_FW_GET));
- set_disable = ((struct ip_fw *)data)-set_disable;
+ bcopy(((struct ip_fw *)data)-next_rule,
+ set_disable, sizeof(set_disable));
+
for (i = 0, msg = disable ; i 31; i++)
if ( (set_disable (1i))) {
@@ -1620,23 +1634,27 @@
for (n = 0, r = data; n nstat;
n++, r = (void *)r + RULESIZE(r)) {
/* packet counter */
- width = snprintf(NULL, 0, %llu, r-pcnt);
+ width = snprintf(NULL, 0, %llu,
+
Re: 5.1-RELEASE TODO
Where do we stand on this now? Is this ready for committing? Is it
completely solved?
Scott
Bernd Walter wrote:
On Sun, Jun 01, 2003 at 03:00:09PM +0200, Bernd Walter wrote:
On Sun, Jun 01, 2003 at 02:26:34AM -0700, Luigi Rizzo wrote:
On Sun, Jun 01, 2003 at 03:32:56AM +0200, Bernd Walter wrote:
...
:)
And I hoped a programmer who knows the source could find out and fix
very quickly.
sorry, i missed the offending line number in your previous email.
I think i missed a in all the first arguments to bcopy in
the src/sbin/ipfw2.c changes :(
this happens at lines 818, 1224, 1461 and 1701. Fortunately
the kernel part seems correct.
In detail, the fix should be the following:
818:
- bcopy(rule-next_rule, set_disable, sizeof(set_disable));
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
1224:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
1461:
- bcopy(((struct ip_fw *)data)-next_rule,
+ bcopy(((struct ip_fw *)data)-next_rule,
1701:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
Look way bettter now :)
I wasn't able to crash the kernel with missaligned access any more, but
the userland tool still does in some situations:
[59]cicely12# ipfw show
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120003bdc ra=0x120003bc8 op=ldq
001005237 824333 allow tcp from any to any dst-port 1-65535,1-65535
00200 0 0 allow tcp from any to any dst-port 1-65535,1-65535,1-65535
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120002260 ra=0x1200015ec op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120002264 ra=0x1200015ec op=ldq
65535 5836817 1002036976 allow ip from any to any
I'm currently using the attached diff to ipfw2.c + your other changes.
It seems to work now.
I hope that I catched all missalignemts that were missing.
Thanks for the work on this.
I'm very happy to see this running on alpha.
Index: ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.23
diff -u -r1.23 ipfw2.c
--- ipfw2.c 15 Mar 2003 01:12:59 - 1.23
+++ ipfw2.c 2 Jun 2003 13:22:30 -
@@ -348,6 +348,14 @@
{ NULL, 0 }
};
+static __inline u_int64_t
+align_uint64(u_int64_t *pll) {
+ u_int64_t ret;
+
+ bcopy (pll, ret, sizeof(ret));
+ return ret;
+};
+
/**
* match_token takes a table and a string, returns the value associated
* with the string (0 meaning an error in most cases)
@@ -813,8 +821,9 @@
int flags = 0; /* prerequisites */
ipfw_insn_log *logptr = NULL; /* set if we find an O_LOG */
int or_block = 0; /* we are in an or block */
+ u_int32_t set_disable;
- u_int32_t set_disable = rule-set_disable;
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
if (set_disable (1 rule-set)) { /* disabled */
if (!show_sets)
@@ -825,8 +834,8 @@
printf(%05u , rule-rulenum);
if (do_acct)
- printf(%*llu %*llu , pcwidth, rule-pcnt, bcwidth,
- rule-bcnt);
+ printf(%*llu %*llu , pcwidth, align_uint64(rule-pcnt),
+ bcwidth, align_uint64(rule-bcnt));
if (do_time) {
char timestr[30];
@@ -1213,13 +1222,16 @@
{
struct protoent *pe;
struct in_addr a;
+ uint16_t rulenum;
if (!do_expired) {
if (!d-expire !(d-dyn_type == O_LIMIT_PARENT))
return;
}
- printf(%05d %*llu %*llu (%ds), d-rulenum, pcwidth, d-pcnt, bcwidth,
+ bcopy(d-rule, rulenum, sizeof(rulenum));
+
+ printf(%05d %*llu %*llu (%ds), rulenum, pcwidth, d-pcnt, bcwidth,
d-bcnt, d-expire);
switch (d-dyn_type) {
case O_LIMIT_PARENT:
@@ -1454,7 +1466,9 @@
err(EX_OSERR, malloc);
if (getsockopt(s, IPPROTO_IP, IP_FW_GET, data, nbytes) 0)
err(EX_OSERR, getsockopt(IP_FW_GET));
- set_disable = ((struct ip_fw *)data)-set_disable;
+ bcopy(((struct ip_fw *)data)-next_rule,
+ set_disable, sizeof(set_disable));
+
for (i = 0, msg = disable ; i 31; i++)
if ( (set_disable (1i))) {
@@ -1620,23 +1634,27 @@
for (n = 0, r = data; n nstat;
n++, r = (void *)r + RULESIZE(r)) {
/* packet counter */
- width = snprintf(NULL, 0, %llu, r-pcnt);
+ width = snprintf(NULL, 0, %llu,
+ align_uint64(r-pcnt));
if (width pcwidth)
pcwidth = width;
/* byte counter */
- width = snprintf(NULL, 0, %llu, r-bcnt);
+ width = snprintf(NULL, 0, %llu,
+ align_uint64(r-bcnt));
if (width bcwidth)
bcwidth = width;
}
}
if (do_dynamic ndyn) {
for (n = 0, d = dynrules; n ndyn; n++, d++) {
- width = snprintf(NULL, 0, %llu, d-pcnt);
+ width = snprintf(NULL, 0, %llu,
+ align_uint64(d-pcnt));
if (width pcwidth)
pcwidth = width;
- width = snprintf(NULL, 0, %llu,
Re: 5.1-RELEASE TODO
On Sun, Jun 01, 2003 at 02:26:34AM -0700, Luigi Rizzo wrote: On Sun, Jun 01, 2003 at 03:32:56AM +0200, Bernd Walter wrote: ... :) And I hoped a programmer who knows the source could find out and fix very quickly. sorry, i missed the offending line number in your previous email. I think i missed a in all the first arguments to bcopy in the src/sbin/ipfw2.c changes :( this happens at lines 818, 1224, 1461 and 1701. Fortunately the kernel part seems correct. In detail, the fix should be the following: 818: - bcopy(rule-next_rule, set_disable, sizeof(set_disable)); + bcopy(rule-next_rule, set_disable, sizeof(set_disable)); 1224: - bcopy(d-rule, rulenum, sizeof(rulenum)); + bcopy(d-rule, rulenum, sizeof(rulenum)); 1461: - bcopy(((struct ip_fw *)data)-next_rule, + bcopy(((struct ip_fw *)data)-next_rule, 1701: - bcopy(d-rule, rulenum, sizeof(rulenum)); + bcopy(d-rule, rulenum, sizeof(rulenum)); Look way bettter now :) I wasn't able to crash the kernel with missaligned access any more, but the userland tool still does in some situations: [59]cicely12# ipfw show pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc op=ldq pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120003bdc ra=0x120003bc8 op=ldq 001005237 824333 allow tcp from any to any dst-port 1-65535,1-65535 00200 0 0 allow tcp from any to any dst-port 1-65535,1-65535,1-65535 pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120002260 ra=0x1200015ec op=ldq pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120002264 ra=0x1200015ec op=ldq 65535 5836817 1002036976 allow ip from any to any [64]cicely12# sysctl machdep.unaligned_sigbus=1 machdep.unaligned_sigbus: 0 - 1 [65]cicely12# ipfw show pid 2146 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc op=ldq Bus error (core dumped) Exit 138 [66]cicely12# gdb ./ipfw ipfw.core GNU gdb 5.2.1 (FreeBSD) Copyright 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 alpha-undermydesk-freebsd... Core was generated by `ipfw'. Program terminated with signal 10, Bus error. #0 0x120003bb4 in list (ac=0, av=0x11fff720) at ipfw2.c:1629 1629width = snprintf(NULL, 0, %llu, r-pcnt); (gdb) bt #0 0x120003bb4 in list (ac=0, av=0x11fff720) at ipfw2.c:1629 #1 0x120007d10 in ipfw_main (ac=1, av=0x11fff718) at ipfw2.c:3486 #2 0x1200084bc in main (ac=2, av=0x11fff710) at ipfw2.c:3637 -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, 1 Jun 2003 09:00:13 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: Areas requiring immediate testing I already reported to -current that I wasn't able to umount a msdosfs slice a while ago (umount failed with busy and the slice was still mounted), last week I had the possibility to test it with a May 25 kernel again and I still wasn't able to umount the msdosfs slice. I tried not with the same harddisk as last time and the slices wheren't created by the same Windows system, so I exclude the possibility of a damaged slice. I try to get time to connect the harddisk again to my system (with a May 30 kernel) before I return the disk, but I think the issue should get added to the list of issues to look at before 5.1 (at least to be able to add it to the errata). Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Alexander Leidinger wrote: On Sun, 1 Jun 2003 09:00:13 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: Areas requiring immediate testing I already reported to -current that I wasn't able to umount a msdosfs slice a while ago (umount failed with busy and the slice was still mounted), last week I had the possibility to test it with a May 25 kernel again and I still wasn't able to umount the msdosfs slice. I tried not with the same harddisk as last time and the slices wheren't created by the same Windows system, so I exclude the possibility of a damaged slice. I try to get time to connect the harddisk again to my system (with a May 30 kernel) before I return the disk, but I think the issue should get added to the list of issues to look at before 5.1 (at least to be able to add it to the errata). Bye, Alexander. I've mounted many MSDOS filesystems recently without problems. Do have any other information about this? Did you verify that there were no open vnodes on the filesystem? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, 01 Jun 2003 11:46:34 -0600 Scott Long [EMAIL PROTECTED] wrote: I've mounted many MSDOS filesystems recently without problems. Do have any other information about this? Did you verify that there were no open vnodes on the filesystem? I just copied 13 GB from the msdosfs to an ufs slice and 8 GB from an ufs to the msdosfs slice. After that the system was idle for a while (several minutes, maybe 2 hours). Then I just did some 'ls' invocations to verify the copy procedure and tried to umount. I hadn't any program running with legitimate access to /mnt and I have no program running which accesses a random filesystem path, so no vnodes should have been open then. At the moment I have a simulation running in the background, so I can't reconnect the harddisk to the system, but I reconnect it tomorrow and present the typescript of the terminal session. Is there a way to set breakpoints in the kernel (no serial console) and if so, what would be interesting to look at? Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, 01 Jun 2003 11:46:34 -0600
Scott Long [EMAIL PROTECTED] wrote:
I've mounted many MSDOS filesystems recently without problems. Do have
any other information about this? Did you verify that there were no
open vnodes on the filesystem?
Simply mounting, reading and umount the fs works:
---snip---
Monday, 02. June 2003, 09:15:01
{0} FreeBSD 5.1-BETA [Magelan:~]
(1) [EMAIL PROTECTED] # mount_msdosfs -l -u netchild /dev/ad1s1 /mnt
Monday, 02. June 2003, 09:15:56
{0} FreeBSD 5.1-BETA [Magelan:~]
(2) [EMAIL PROTECTED] # du -hd0 /mnt
22G/mnt
Monday, 02. June 2003, 09:16:26
{0} FreeBSD 5.1-BETA [Magelan:~]
(3) [EMAIL PROTECTED] # umount /mnt
---snip---
This is the problem case:
---snip---
Monday, 02. June 2003, 09:16:31
{0} FreeBSD 5.1-BETA [Magelan:~]
(4) [EMAIL PROTECTED] # mount_msdosfs -l -u netchild /dev/ad1s1 /mnt
Monday, 02. June 2003, 09:16:40
{0} FreeBSD 5.1-BETA [Magelan:~]
(5) [EMAIL PROTECTED] # cp ftpchroot-test.sh /mnt
Monday, 02. June 2003, 09:16:59
{0} FreeBSD 5.1-BETA [Magelan:~]
(6) [EMAIL PROTECTED] # cp /mnt/ftpchroot-test.sh /tmp/
Monday, 02. June 2003, 09:17:12
{0} FreeBSD 5.1-BETA [Magelan:~]
(7) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
Monday, 02. June 2003, 09:17:15
{1} FreeBSD 5.1-BETA [Magelan:~]
(8) [EMAIL PROTECTED] # sync;sync;sync
Monday, 02. June 2003, 09:17:22
{0} FreeBSD 5.1-BETA [Magelan:~]
(9) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
---snip---
The copied file has a size of 212 bytes.
Bye,
Alexander.
--
It's not a bug, it's tradition!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
-snip-
Monday, 02. June 2003, 09:16:59
{0} FreeBSD 5.1-BETA [Magelan:~]
(6) [EMAIL PROTECTED] # cp /mnt/ftpchroot-test.sh /tmp/
Monday, 02. June 2003, 09:17:12
{0} FreeBSD 5.1-BETA [Magelan:~]
(7) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
Monday, 02. June 2003, 09:17:15
{1} FreeBSD 5.1-BETA [Magelan:~]
(8) [EMAIL PROTECTED] # sync;sync;sync
Monday, 02. June 2003, 09:17:22
{0} FreeBSD 5.1-BETA [Magelan:~]
(9) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
---snip---
Umm shouldn't you be trying to umount /mnt ?
--
Mark Sergeant [EMAIL PROTECTED]
SNSOnline Technical Services
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On 02 Jun 2003 17:38:28 +1000 Mark Sergeant [EMAIL PROTECTED] wrote: Umm shouldn't you be trying to umount /mnt ? I retested this and now used /mnt in the umount invocation... (blushI hope I'm awake now./blush). It umounts now successfully. I noticed some commits to the vfs layer between my last kernel and the actual one, either the bug is fixed now (I'm sure last time I had the problems I used /mnt in the umount invocation, not any other mounted FS), or the bug only get's triggered only in a specific situation I wasn't able to reproduce now. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Alexander Leidinger wrote: On Sun, 01 Jun 2003 11:46:34 -0600 Scott Long [EMAIL PROTECTED] wrote: I've mounted many MSDOS filesystems recently without problems. Do have any other information about this? Did you verify that there were no open vnodes on the filesystem? I just copied 13 GB from the msdosfs to an ufs slice and 8 GB from an ufs to the msdosfs slice. After that the system was idle for a while (several minutes, maybe 2 hours). Then I just did some 'ls' invocations to verify the copy procedure and tried to umount. I hadn't any program running with legitimate access to /mnt and I have no program running which accesses a random filesystem path, so no vnodes should have been open then. Alas, lsof (ports) would be a better way of checking if there are vnodes open or not. I think fstat does that too, but I'm too used to lsof. Also, what is the error message? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Spellng is overated anywy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sat, May 31, 2003 at 09:00:16AM -0400, Robert Watson wrote: This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ i posted patches and a detailed description for this item 3 weeks ago to re@ and then the same was forwarded a couple of weeks ago to the relevant lists (ipfw, sparc64, alpha) and got no useful feedback (in detail, two message: one 'cannot apply the patch', the other one 'it dumps core' without further details). As i do not have access to these platforms, all i can do is provide code and make sure that it compiles (which i did, using a cross-build), but for running it (part of the problem involves the kernel) i need someone with rootconsole access to test them. I would interpret the absence of feedback as a nobody cares enough (which is perfectly fine given that these platforms are a negligible fraction of the installed base, there are more important issues to address and these particular ones should have a relatively trivial fix). cheers luigi Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. |
Re: 5.1-RELEASE TODO
Luigi Rizzo wrote: On Sat, May 31, 2003 at 09:00:16AM -0400, Robert Watson wrote: This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ i posted patches and a detailed description for this item 3 weeks ago to re@ and then the same was forwarded a couple of weeks ago to the relevant lists (ipfw, sparc64, alpha) and got no useful feedback (in detail, two message: one 'cannot apply the patch', the other one 'it dumps core' without further details). As i do not have access to these platforms, all i can do is provide code and make sure that it compiles (which i did, using a cross-build), but for running it (part of the problem involves the kernel) i need someone with rootconsole access to test them. I would interpret the absence of feedback as a nobody cares enough (which is perfectly fine given that these platforms are a negligible fraction of the installed base, there are more important issues to address and these particular ones should have a relatively trivial fix). cheers luigi Luigi, It's been a matter of not having enough time, nothing more. I *will* address this one way or another before the release. I apologize for taking so long. Scott Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || |
Re: 5.1-RELEASE TODO
On Sat, 31 May 2003, Scott Long wrote: It's been a matter of not having enough time, nothing more. I *will* address this one way or another before the release. I apologize for taking so long. Ditto, here, unfortunately. I managed to hose my sparc64 box a couple of weeks ago trying to upgrade it to run precisely these tests, but haven't had time to figure out how to recover it. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
If memory serves me right, Scott Long wrote: It's been a matter of not having enough time, nothing more. I *will* address this one way or another before the release. I apologize for taking so long. Scott, you're hardly the only person with the ability to test this problem. In fact, you're not even personally affected by this. So don't be too hard on yourself. Luigi, thanks for coming up with a patch...can't remember if I said that before. I'm mystified as to why nobody's stepped forward to help you test it. Bruce. pgp0.pgp Description: PGP signature
Re: 5.1-RELEASE TODO
On Sat, May 31, 2003 at 02:24:59PM -0700, Luigi Rizzo wrote: On Sat, May 31, 2003 at 09:00:16AM -0400, Robert Watson wrote: ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ i posted patches and a detailed description for this item 3 weeks ago to re@ and then the same was forwarded a couple of weeks ago to the relevant lists (ipfw, sparc64, alpha) and got no useful feedback (in detail, two message: one 'cannot apply the patch', the other one 'it dumps core' without further details). A gdb stacktrace is much more than without further details. It happened inside bcopy. I asumed that the stacktrace including the sourceline calling bcopy would be enough. If you need more then you should say so - I can't guess. As i do not have access to these platforms, all i can do is provide code and make sure that it compiles (which i did, using a cross-build), but for running it (part of the problem involves the kernel) i need someone with rootconsole access to test them. I would interpret the absence of feedback as a nobody cares enough (which is perfectly fine given that these platforms are a negligible fraction of the installed base, there are more important issues to address and these particular ones should have a relatively trivial fix). It's a chick egg problem - if software regulary fails then less users will use such hardware or at least avoid that kind of software. Don't get me wrong: ipfw is good software which I use daily (on i386) and I'm happy about the recent features you did, but there are two sides of the story. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sat, May 31, 2003 at 08:18:10PM -0400, Robert Watson wrote: On Sat, 31 May 2003, Scott Long wrote: It's been a matter of not having enough time, nothing more. I *will* address this one way or another before the release. I apologize for taking so long. Ditto, here, unfortunately. I managed to hose my sparc64 box a couple of weeks ago trying to upgrade it to run precisely these tests, but haven't had time to figure out how to recover it. no need to apologize, as i said i am perfectly fine with people not having time, and surely the RE team is taken by more urgent issues these days. My mail was meant just as a reminder, nothing more. As for the patch i posted: i don't claim it to be perfect, it might contain some trivial bug such as passing the wrong variable to a function, but hopefully those are things that a programmer who has access to the box can find out and fix very quickly. cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sat, May 31, 2003 at 05:39:58PM -0700, Luigi Rizzo wrote: On Sat, May 31, 2003 at 08:18:10PM -0400, Robert Watson wrote: On Sat, 31 May 2003, Scott Long wrote: It's been a matter of not having enough time, nothing more. I *will* address this one way or another before the release. I apologize for taking so long. Ditto, here, unfortunately. I managed to hose my sparc64 box a couple of weeks ago trying to upgrade it to run precisely these tests, but haven't had time to figure out how to recover it. no need to apologize, as i said i am perfectly fine with people not having time, and surely the RE team is taken by more urgent issues these days. My mail was meant just as a reminder, nothing more. As for the patch i posted: i don't claim it to be perfect, it might contain some trivial bug such as passing the wrong variable to a function, but hopefully those are things that a programmer who has access to the box can find out and fix very quickly. :) And I hoped a programmer who knows the source could find out and fix very quickly. To be honest - I did not investigate the reason for the failure as there were other things on my todo list. Well after getting some sleep I will check that again. Nevertheless here are the stack traces again - in case someone else can identify the cause in the meantime: cicely12# ipfw flush Are you sure? [yn] y Flushed all rules. cicely12# ipfw show Segmentation fault (core dumped) cicely12# May 23 17:09:50 cicely12 kernel: pid 601 (ipfw), uid 0: exited on signal 11 (core dumped) cicely12# gdb /usr/obj/var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw ipfw.core GNU gdb 5.2.1 (FreeBSD) Copyright 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 alpha-undermydesk-freebsd... Core was generated by `ipfw'. Program terminated with signal 11, Segmentation fault. #0 0x120044794 in bcopy () (gdb) bt #0 0x120044794 in bcopy () #1 0x120001564 in show_ipfw (rule=0x1200ac000, pcwidth=3, bcwidth=5) at /var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw2.c:818 (gdb) cicely12# ipfw add allow ip from any to any Segmentation fault (core dumped) cicely12# May 23 17:13:40 cicely12 kernel: pid 644 (ipfw), uid 0: exited on signal 11 (core dumped) cicely12# gdb /usr/obj/var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw ipfw.core GNU gdb 5.2.1 (FreeBSD) Copyright 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 alpha-undermydesk-freebsd... Core was generated by `ipfw'. Program terminated with signal 11, Segmentation fault. #0 0x120044794 in bcopy () (gdb) bt #0 0x120044794 in bcopy () #1 0x120001564 in show_ipfw (rule=0x120099cb0, pcwidth=10, bcwidth=10) at /var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw2.c:818 warning: Hit beginning of text section without finding warning: enclosing function for address 0x8 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. (gdb) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, Jun 01, 2003 at 03:32:56AM +0200, Bernd Walter wrote: ... :) And I hoped a programmer who knows the source could find out and fix very quickly. sorry, i missed the offending line number in your previous email. I think i missed a in all the first arguments to bcopy in the src/sbin/ipfw2.c changes :( this happens at lines 818, 1224, 1461 and 1701. Fortunately the kernel part seems correct. In detail, the fix should be the following: 818: - bcopy(rule-next_rule, set_disable, sizeof(set_disable)); + bcopy(rule-next_rule, set_disable, sizeof(set_disable)); 1224: - bcopy(d-rule, rulenum, sizeof(rulenum)); + bcopy(d-rule, rulenum, sizeof(rulenum)); 1461: - bcopy(((struct ip_fw *)data)-next_rule, + bcopy(((struct ip_fw *)data)-next_rule, 1701: - bcopy(d-rule, rulenum, sizeof(rulenum)); + bcopy(d-rule, rulenum, sizeof(rulenum)); thanks luigi To be honest - I did not investigate the reason for the failure as there were other things on my todo list. Well after getting some sleep I will check that again. Nevertheless here are the stack traces again - in case someone else can identify the cause in the meantime: cicely12# ipfw flush Are you sure? [yn] y Flushed all rules. cicely12# ipfw show Segmentation fault (core dumped) cicely12# May 23 17:09:50 cicely12 kernel: pid 601 (ipfw), uid 0: exited on signal 11 (core dumped) cicely12# gdb /usr/obj/var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw ipfw.core GNU gdb 5.2.1 (FreeBSD) Copyright 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 alpha-undermydesk-freebsd... Core was generated by `ipfw'. Program terminated with signal 11, Segmentation fault. #0 0x120044794 in bcopy () (gdb) bt #0 0x120044794 in bcopy () #1 0x120001564 in show_ipfw (rule=0x1200ac000, pcwidth=3, bcwidth=5) at /var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw2.c:818 (gdb) cicely12# ipfw add allow ip from any to any Segmentation fault (core dumped) cicely12# May 23 17:13:40 cicely12 kernel: pid 644 (ipfw), uid 0: exited on signal 11 (core dumped) cicely12# gdb /usr/obj/var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw ipfw.core GNU gdb 5.2.1 (FreeBSD) Copyright 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 alpha-undermydesk-freebsd... Core was generated by `ipfw'. Program terminated with signal 11, Segmentation fault. #0 0x120044794 in bcopy () (gdb) bt #0 0x120044794 in bcopy () #1 0x120001564 in show_ipfw (rule=0x120099cb0, pcwidth=10, bcwidth=10) at /var/d3/FreeBSD-2003-05-22/src/sbin/ipfw/ipfw2.c:818 warning: Hit beginning of text section without finding warning: enclosing function for address 0x8 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. (gdb) -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sat, 31 May 2003, Robert Watson wrote: |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| Got a Lucent mini-pci card in my laptop and a Lucent(Avaya) Gold card. I don't see any problems with both cards. Regards, Richard. Paul Vixie in an interview with Sendmail.net: Now that the Internet has the full spectrum of humanity as users, the technology is showing its weakness: it was designed to be used by friendly, smart people. Spammers, as an example of a class, are neither friendly nor smart. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
John Baldwin wrote: On 14-May-2003 Terry Lambert wrote: The DISABLE_PG_G, as I said in a previous posting, works around an order of operation problem that needs to clear PG in %CR0 while it does it's thing, after which there's no problem with enabling it. See IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide for more details on PG_G, the PG bit in %CR0, and the effect on TLB flushing; look specifically at Section 10.9 of Memory Cache Control, which is entitled Invalidating The TRanslation Lookaside Buffers. Specifically, writing %CR3 doesn't invalidate pages with PG_G set on them if PG is set in %CR0. Umm, Terry, that's the whole point of PGE. You don't flush entries from the TLB that are global, i.e. shared among all processes and don't change. Duh. Basically your suggestion would be an expensive hack equivalent to DISABLE_PG_G. No. My suggestion would be to not load something into a global page before some of the VM system mappings have been established. Basically, there is some machdep.c code that's out of order. Reordering it is hard, so I haven't done it yet. In other words, the problem is that someone is enabling PG in %CR0 way too early. Read the first sentence again: ...works around an order of operation problem I think if you check the archives back to when I first started recommending that both DISABLE_PSE and DISABLE_PG_G be used, rather than just DISABLE_PSE, it comes down to the machdep.c and locore.s reorganization, where I complained that the new order of operation had problems. This happened back before the 5.0 DP1. My suggestion then was revert the changes; barring that, someone is going to have to sit down and go through the new code, like I went through the old code, and understand where every byte of memory is coming from, and how and when it gets into the memory map. I personally think this is probably the responsibility of the people who changed the code and broke use of PG in the first place. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
