Re: different packing of structs in kernel vs. userland ?
Luigi Rizzo wrote:
Hi,
the following message seems to suggest that the compiler
(the way it is invoked) packs structures differently
when building the kernel and userland.
The stize of the structure in question is computed
by both kernel and userland app using sizeof(),
so there is no assumption on the size of its members,
so i believe the only possibility of a mismatch is
the one above.
Any ideas ?
Probably a #pragma pack() in scope.
Add one explicitly before and after the structure definition
to force it to be the same in user space and the kernel, e.g.:
#pragma pack(1) /* 1 byte packing */
struct foo {
...
};
#pragma pack() /* whatever it was before */
The latter is like a pop of the former's push, so you
should be OK, even though it looks like what is happening
is an include of an include file in the wrong place or in
code that has one in scope.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
SCSI emulation in FreeBSD
Hi, I was scratching around the geocrawler archives yesterday, looking for information on using SCSI emulation in FBSD. I found some, but was dumb enough (yet again) not to bookmark it. I've synced my source with -CURRENT, and looked through all the options I could find, even a home-made LINT, still nothing. I read about a patch in the old message I found. Am I simply not seeing the options I want, or do I need to patch my kernel for this to work? The reason I want this is that I have an HP 9110 CD-RW drive. It refuses to work properly with the ATA drivers, and I refuse to reboot to Windows every time I just want to burn a CD. Anybody have any idea what I need and where I can find it? Regards, Will -- Willie Viljoen Highveld Computing Solutions 214 Paul Kruger Avenue Universitas Bloemfontein 9321 South Africa +27 51 522 15 60, a/h +27 51 522 44 36 +27 82 404 03 27 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI emulation in FreeBSD
Anybody have any idea what I need and where I can find it? http://www.cuivre.fr.eu.org/~thomas/atapicam/ Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current perforamnce.
Just a note for those following these things... Not of great importance, as we know that -current performance will go up and down, but I just noticed we lost 1.5% since the 9th on the worldstone test. (real time numbers. several runs) July 14 kernel 3441.946u 1492.986s 1:32:01.33 89.3%2726+2167k 33431+154651io 11217pf+0w July 9 kernel 3433.348u 1475.230s 1:30:31.24 90.3%2724+2169k 35689+154653io 10978pf+0w (1.5 minutes out of 90 minutes) Uniprocessor machine, 1 IDE drive.. Witness etc all ON, so don't panic about this.. It may be all the extra locking going on in the VM system.. Copyright (c) 1992-2002 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 #24: Tue Jul 9 16:00:31 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/REF3 Preloaded elf kernel /boot/kernel.old/kernel at 0xc049b000. Preloaded elf module /boot/kernel.old/acpi.ko at 0xc049b0ac. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 863868732 Hz CPU: Pentium III/Pentium III Xeon/Celeron (863.87-MHz 686-class CPU) Origin = GenuineIntel Id = 0x68a Stepping = 10 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 267124736 (260864K bytes) avail memory = 254398464 (248436K bytes) Pentium Pro MTRR support enabled Using $PIR table, 12 entries at 0xc00f2f70 [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === gnu/lib/libobjc === gnu/lib/libg2c === gnu/usr.bin === gnu/usr.bin/bc === gnu/usr.bin/binutils === gnu/usr.bin/binutils/libiberty === gnu/usr.bin/binutils/libbfd cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c: In function `_bfd_elf_discard_section_eh_frame': /usr/home/des/tinderbox/sparc64/src/contrib/binutils/bfd/elf-eh-frame.c:417: warning: comparison between signed and unsigned *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/binutils/libbfd. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin/binutils. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu/usr.bin. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/gnu. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Please review and commit : Revised rpcgen (1) patch updated
Hi all, I reworked my patch as from PR bin/29175 and the PR misc/27816. http://people.freebsd.org/~mbr/patches/rpcgen.diff Some comments about the patch. - TI-RPC is now the default again for code generation. Unbreaks ports/mail/drac for CURRENT. - As before, inetd support support is turned of per default. Code for inetd can be made with -I. - Support for ``transport monitors'' and the NLSPROVIDER env variable is still there , even if their use is not clear in non TLI stream based systems like Free-/NetBSD. It can be activated with -P. - There are a few corrections in rpcgen.1 and usage function to conform to the code. Added and documented -P - I removed the #ifdefs checks for Free-/NetBSD since we are the only ones who use this code. MaxOS X may have the same limitations as we have, so this code will correctly build for them. - Generate correct cflags. Patch is based on my work and Jean-Luc Richier [EMAIL PROTECTED]. Comments are welcome. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Interesting panic very early in the boot
Hello everybody, I have recently finished to upgrade my system to today morning's -CURRENT, with sources just *before* the commit of rev 1.154 to src/sys/kern/kern_fork.c by Julian. I have an UP IA32 machine, I am not using any additional kernel modules, and now, upon rebooting with the new kernel, as soon as I allow to continue from the loader prompt, the kernel greets me with this: (No serial console, transcribed by hand, please excuse any typos) Fatal trap 12: page fault within kernel mode fault virtual address = 0xbff004c0 fault code = supervisor read, protection violation instruction pointer = 0x8:0xc035c348 stack pointer = 0x10:0xc0532c08 frame pointer = 0x10:0xc0532c10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 0 () kernel: type 12 trap, code=0 Stopped at 0xc035c348: cmpl $0,0xbfc0(%eax) Unfortunately, there is preciously little I could extract from ddb after this. ddb ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 0 c03f00c0 c053 0 0 000 New ddb tr (null)(c0418920,c080,537000,c0532d48,c03595bd) at 0xc035c348 (null)(537000,0,c0532c9c,c0532ce8,10) at 0xc035c290 (null)(537000,c0352524,f,0,8) at 0xc03595bd (null)(537000) at 0xc0359fb9 (null)() at 0xc0130c7d An attempt to show locks resulted in: witness_list: witness_cold Fatal trap 3 breakpoint instruction fault while in kernel mode An attempt to show witness resulted in: witness_display: witness_cold Uptime 1s and a complete lockup, only a power-cycle helped. No dump was taken. Does this ring a bell with anyone? I know that the trace may not help much... I will be just too glad to offer any information or testing that may be needed. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
On Sun, Jul 14, 2002 at 07:49:57PM +0200, Szilveszter Adam wrote: Hello everybody, I have recently finished to upgrade my system to today morning's -CURRENT, with sources just *before* the commit of rev 1.154 to src/sys/kern/kern_fork.c by Julian. I have an UP IA32 machine, I am not using any additional kernel modules, and now, upon rebooting with the new kernel, as soon as I allow to continue from the loader prompt, the kernel greets me with this: ... Sorry I should have said that I have ACPI compiled into the kernel, but it is apparently not supported by the motherboard. Will try without it next. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Please review and commit : Revised rpcgen (1) patch updated
I'm still upset that we don't have tirpc99, when do you plan on porting that over? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
On Fri, Jul 12, 2002 at 05:29:01PM -0600, Eric Anholt wrote: well if you give me details, i could try cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri login cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/dri -z3 co -P xc details snipped/ ok i'll try :-) I am not a kernel hacker, so MMMV (my mileage my vary:-) -tacho To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI emulation in FreeBSD
Anybody have any idea what I need and where I can find it? http://www.cuivre.fr.eu.org/~thomas/atapicam/ Just as a datapoint, I recently applied the ATAPI/CAM patches to a -STABLE from July 10th). They applied flawlessly, compile was clean. My newly-acquired TEAC DW-28E CDR/CDRW/DVD drive now works perfectly with the SCSI cdrecord from ports. And thanks to 'atacontrol', I can even hot-swap IDE devices in and out of the laptop modular bay. This OS rocks!! Thanks to all for their efforts. I would be even happier if the ATAPI-CAM patches could finally be integrated, so I didn't have to apply them manually after each cvsup. Regards, AS msg41004/pgp0.pgp Description: PGP signature
Re: SCSI emulation in FreeBSD
Just to follow up, I went back to -STABLE after discovering I don't need -current to do this (*slight sigh of reliefe*) Thanks Jan and Thomas, it works perfectly with both my BTC 36x ATAPI CD-ROM and the HP CD-Writer+ 9110. Thomas, ever consider asking for it to be committed into FreeBSD proper, atleast maybe into -current? The code is really good IMHO. Those ILLEGAL_REQUEST warnings come from that ATA driver, and they shouldn't scare anybody, but for the really paranoid, I'm sure they could be eliminated by some extra options for the ata(4) driver to allow us to silence error output (Soren?) Anyway, thanks for the quick replies. Also, I see Thomas's address in the list of CCs, I unsubscribed from freebsd-current after getting it fixed, so I missed what ever message he was involved in (if there was one) and I'd love to read it, so I'd appreciate it if somebody could forward it to me :) Regards, Will On Sun, 14 Jul 2002, Andy Sparrow wrote: Anybody have any idea what I need and where I can find it? http://www.cuivre.fr.eu.org/~thomas/atapicam/ Just as a datapoint, I recently applied the ATAPI/CAM patches to a -STABLE from July 10th). They applied flawlessly, compile was clean. My newly-acquired TEAC DW-28E CDR/CDRW/DVD drive now works perfectly with the SCSI cdrecord from ports. And thanks to 'atacontrol', I can even hot-swap IDE devices in and out of the laptop modular bay. This OS rocks!! Thanks to all for their efforts. I would be even happier if the ATAPI-CAM patches could finally be integrated, so I didn't have to apply them manually after each cvsup. Regards, AS -- Willie Viljoen Highveld Computing Solutions 214 Paul Kruger Avenue Universitas Bloemfontein 9321 South Africa +27 51 522 15 60, a/h +27 51 522 44 36 +27 82 404 03 27 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI Sony FX601
On Fri, Jul 12, 2002 at 07:50:00PM +0200, Michael Bretterklieber wrote:
Hi,
I installed FreeBSD 5.0-current on my notebook, because in FreeBSD4.6
the sounddriver let the kernel hang on boot.
I know, that acpi is under developement, but here are my results testing
acpi on this hardware.
acpiconf -s 3:
works, but the machine doesen't completely wake up, the display still
stays dark
acpiconf -s 4:
the system hangs uo.
i'll report i'm seeing the same problems on my vaio pcg-f430. acpi works for cpu
speed stepping but not for suspends/resume stuff.
/*
RSD PTR: Checksum=59, OEMID=SONY, RsdtAddress=0x07ffcf48
*/
/*
RSDT: Length=44, Revision=1, Checksum=119,
OEMID=SONY, OEM Table ID=K1, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
*/
/*
Entries={ 0x07fffb65, 0x07fffbd9 }
*/
/*
DSDT=0x7ffcf74
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x8000-0x8003
PM1a_CNT_BLK=0x8042-0x8043
PM2_TMR_BLK=0x8008-0x800b
PM2_GPE0_BLK=0x800c-0x800f
P_LVL2_LAT=10ms, P_LVL3_LAT=101ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
Flags={WBINVD,SLP_BUTTON,RTC_S4}
*/
is there more information needed to help get this working w/ current?
--
Jacob I'm Brainy For Zombie Pops Frelinger
Jolly at TheCoffinClub dot Com
http://www.thecoffinclub.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATAPI/SCSI emulation in FreeBSD
About a year ago I pushed for this to be integrated and at that time there were lots of comments about not being done correctly and it will be done corectly soon. well another year or so ha spassed and people are STILL having to apply the patches manually. Can I suggest that the code be applied now as is, and that if someone really doesn't like it they can fix it later when they get the time? It's one thong to say It's not done right and hold off as I'm going to fix it It's quite a different matter to say Hold off on this functionality as I don't like it but I have no plans to produce any equivalent funcionality On Sun, 14 Jul 2002, Thomas Quinot wrote: Le 2002-07-14, Willie Viljoen écrivait : Just to follow up, I went back to -STABLE after discovering I don't need -current to do this (*slight sigh of reliefe*) Yep, I do most ATAPI/CAM develoment on -STABLE machines. Thomas, ever consider asking for it to be committed into FreeBSD proper, atleast maybe into -current? This is being considered, but I am not the one who can make the decision on this issue. If you'd like to see the code integrated into -CURRENT, you should let Søren know ([EMAIL PROTECTED]). The code is really good IMHO. Those ILLEGAL_REQUEST warnings come from that ATA driver, and they shouldn't scare anybody, but for the really paranoid, I'm sure they could be eliminated by some extra options for the ata(4) driver to allow us to silence error output (Soren?) Well, the ATA driver just reports whatever error condition comes from the drive. The real solution may involve modifying the SCSI device drivers (cd/sa/da) so that they do not send commands that may not work with specific targets, or filtering requests to translate them into the restricted command set that ATAPI units support (this is done in an ad hoc fasion in atapi-cam currently, but there is also work in progress for a general command filtering framework in -CURRENT). Thomas. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
On Sun, Jul 14, 2002 at 08:06:49PM +0200, Szilveszter Adam wrote: On Sun, Jul 14, 2002 at 07:49:57PM +0200, Szilveszter Adam wrote: Hello everybody, I have recently finished to upgrade my system to today morning's -CURRENT, with sources just *before* the commit of rev 1.154 to src/sys/kern/kern_fork.c by Julian. I have an UP IA32 machine, I am not using any additional kernel modules, and now, upon rebooting with the new kernel, as soon as I allow to continue from the loader prompt, the kernel greets me with this: ... Sorry I should have said that I have ACPI compiled into the kernel, but it is apparently not supported by the motherboard. Will try without it next. I upgraded the kernel source and removed ACPI from the config, but still no joy. Something fishy going on here... -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
On Sun, 2002/07/14 at 01:18:10 -0700, Luigi Rizzo wrote:
Hi,
the following message seems to suggest that the compiler
(the way it is invoked) packs structures differently
when building the kernel and userland.
The stize of the structure in question is computed
by both kernel and userland app using sizeof(),
so there is no assumption on the size of its members,
so i believe the only possibility of a mismatch is
the one above.
Any ideas ?
(Disclaimer: my solution below is untested, so it may all be bogus)
No, you are not accounting for external structure padding. Take a
look:
struct ip_fw {
struct ip_fw *next; /* linked list of rules */
u_int16_t act_ofs;/* offset of action in 32-bit units */
u_int16_t cmd_len;/* # of 32-bit words in cmd */
u_int16_t rulenum;/* rule number */
u_int16_t _pad; /* padding */
/* These fields are present in all rules. */
u_int64_t pcnt; /* Packet counter */
u_int64_t bcnt; /* Byte counter */
u_int32_t timestamp; /* tv_sec of last match */
struct ip_fw *next_rule; /* ptr to next rule */
ipfw_insn cmd[1]; /* storage for commands */
};
On a 64-bit architecture, pointers are obviously 8 bytes in size;
structure members must or should be on natural borders, depending on
the architecture.
So, next_rule will not be on a natural border; 4 bytes of padding will
be inserted before it. With that, the total structure size would be
52.
The compiler must account for the fact that an array of struct ip_fws
may be used. For obvious reasons, it can not just insert extra padding
in the array case; instead, the structure size must be chosen so that
in this situation, the first member will be on a natural border.
This results in an extra 4 bytes of external padding at the end,
after the member 'cmd'.
The macro you use to compute the size in the kernel is:
#define RULESIZE(rule) (sizeof(struct ip_fw) + \
((struct ip_fw *)(rule))-cmd_len * 4 - 4)
In the userland code, you start at foo.cmd and append data
directly. This means that the padding will also be used to store
data, so the '- 4' (= sizeof(foo.cmd)) will not always be enough. The
following definition of RULESIZE (untested) should fix this:
#define RULESIZE(rule) (offsetof(struct ip_fw, cmd) + \
((struct ip_fw *)(rule))-cmd_len * 4)
It also removes the explicit 4 for sizeof(ipfw_insn).
- thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
[i am deliberately not trimming the email in case someone wants to
look at the context]
i am a bit dubious about your explaination -- it also does not
explain why the person reporting this problem fixed that
by swapping timestamp and next_rule in the structure
cheers
luigi
On Sun, Jul 14, 2002 at 10:36:42PM +0200, Thomas Moestl wrote:
On Sun, 2002/07/14 at 01:18:10 -0700, Luigi Rizzo wrote:
Hi,
the following message seems to suggest that the compiler
(the way it is invoked) packs structures differently
when building the kernel and userland.
The stize of the structure in question is computed
by both kernel and userland app using sizeof(),
so there is no assumption on the size of its members,
so i believe the only possibility of a mismatch is
the one above.
Any ideas ?
(Disclaimer: my solution below is untested, so it may all be bogus)
No, you are not accounting for external structure padding. Take a
look:
struct ip_fw {
struct ip_fw *next; /* linked list of rules */
u_int16_t act_ofs;/* offset of action in 32-bit units */
u_int16_t cmd_len;/* # of 32-bit words in cmd */
u_int16_t rulenum;/* rule number */
u_int16_t _pad; /* padding */
/* These fields are present in all rules. */
u_int64_t pcnt; /* Packet counter */
u_int64_t bcnt; /* Byte counter */
u_int32_t timestamp; /* tv_sec of last match */
struct ip_fw *next_rule; /* ptr to next rule */
ipfw_insn cmd[1]; /* storage for commands */
};
On a 64-bit architecture, pointers are obviously 8 bytes in size;
structure members must or should be on natural borders, depending on
the architecture.
So, next_rule will not be on a natural border; 4 bytes of padding will
be inserted before it. With that, the total structure size would be
52.
The compiler must account for the fact that an array of struct ip_fws
may be used. For obvious reasons, it can not just insert extra padding
in the array case; instead, the structure size must be chosen so that
in this situation, the first member will be on a natural border.
This results in an extra 4 bytes of external padding at the end,
after the member 'cmd'.
The macro you use to compute the size in the kernel is:
#define RULESIZE(rule) (sizeof(struct ip_fw) + \
((struct ip_fw *)(rule))-cmd_len * 4 - 4)
In the userland code, you start at foo.cmd and append data
directly. This means that the padding will also be used to store
data, so the '- 4' (= sizeof(foo.cmd)) will not always be enough. The
following definition of RULESIZE (untested) should fix this:
#define RULESIZE(rule) (offsetof(struct ip_fw, cmd) + \
((struct ip_fw *)(rule))-cmd_len * 4)
It also removes the explicit 4 for sizeof(ipfw_insn).
- thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: different packing of structs in kernel vs. userland ?
On Sun, 2002/07/14 at 13:43:37 -0700, Luigi Rizzo wrote: [i am deliberately not trimming the email in case someone wants to look at the context] i am a bit dubious about your explaination -- it also does not explain why the person reporting this problem fixed that by swapping timestamp and next_rule in the structure It does - doing so removes the need for padding before 'next_rule', because it is properly aligned then. 'timestamp' and 'cmd' are both 4 bytes in size and immediately follow each other, so the total structure size is a multiple of 8 (48 bytes). Because of that, no padding after 'cmd' is required, and the effect is gone. - thomas -- Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/ [EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mysterious dead-locks with system ssh
Hi! I'm getting strange dead-locks/complete lookups when I use the system ssh with port forwarding. Using something like: ssh -L8080:remote:8080 account@remote to forward a remote apache to my local box. When I access http://localhost:8080/ not later than the third click on link (or pressing reload) my box locks up completely. I don't even get into the debugger or get a crash dump. The box is just plain dead. Though normal SSH works perfectly and accessing a local (not forwarded) apache works, too. The world and kernel is of today and IIRC this actually did work last week (or the week before). Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mysterious dead-locks with system ssh
On Sun, Jul 14, 2002 at 11:08:07PM +0200, Marc Recht wrote: I'm getting strange dead-locks/complete lookups when I use the system ssh with port forwarding. Using something like: ssh -L8080:remote:8080 account@remote to forward a remote apache to my local box. When I access http://localhost:8080/ not later than the third click on link (or pressing reload) my box locks up completely. I don't even get into the debugger or get a crash dump. The box is just plain dead. Though I had a similar problem w/ netscape-4 configured to use a local (non started) proxy in -stable. w/ the proxy, no problem, w/o it, plain dead-lock. don't know where is the lockup ? Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Interesting panic very early in the boot
you can use addr2line to get info, but at a pinch you can just use nm -n to figure out what function each address is in. On Sun, 14 Jul 2002, Szilveszter Adam wrote: Hello everybody, I have recently finished to upgrade my system to today morning's -CURRENT, with sources just *before* the commit of rev 1.154 to src/sys/kern/kern_fork.c by Julian. I have an UP IA32 machine, I am not using any additional kernel modules, and now, upon rebooting with the new kernel, as soon as I allow to continue from the loader prompt, the kernel greets me with this: (No serial console, transcribed by hand, please excuse any typos) Fatal trap 12: page fault within kernel mode fault virtual address = 0xbff004c0 fault code = supervisor read, protection violation instruction pointer = 0x8:0xc035c348 stack pointer = 0x10:0xc0532c08 frame pointer = 0x10:0xc0532c10 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 0 () kernel: type 12 trap, code=0 Stopped at 0xc035c348: cmpl $0,0xbfc0(%eax) Unfortunately, there is preciously little I could extract from ddb after this. ddb ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 0 c03f00c0 c053 0 0 000 New ddb tr (null)(c0418920,c080,537000,c0532d48,c03595bd) at 0xc035c348 (null)(537000,0,c0532c9c,c0532ce8,10) at 0xc035c290 (null)(537000,c0352524,f,0,8) at 0xc03595bd (null)(537000) at 0xc0359fb9 (null)() at 0xc0130c7d An attempt to show locks resulted in: witness_list: witness_cold Fatal trap 3 breakpoint instruction fault while in kernel mode An attempt to show witness resulted in: witness_display: witness_cold Uptime 1s and a complete lockup, only a power-cycle helped. No dump was taken. Does this ring a bell with anyone? I know that the trace may not help much... I will be just too glad to offer any information or testing that may be needed. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Out of disk space on snapshots-jp?
No, the problem is because the kernel has grown too large to fit on the md(4) filesystem prepared for it. src/release/ARCH/dokern.sh needs to be adapted to omit new drivers added to GENERIC. Cheers, Jerry Hicks [EMAIL PROTECTED] On Saturday, July 13, 2002, at 12:21 PM, Donny Lee wrote: Hi there, it looks like the past few days snapshots build failures were all because out of disk space on the snapshots-jp box. -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Out of disk space on snapshots-jp?
Ooh... yuh, i didn't read into detail of the log. -- // Donny W Gerald Hicks wrote: No, the problem is because the kernel has grown too large to fit on the md(4) filesystem prepared for it. src/release/ARCH/dokern.sh needs to be adapted to omit new drivers added to GENERIC. it looks like the past few days snapshots build failures were all because out of disk space on the snapshots-jp box. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Out of disk space on snapshots-jp?
W Gerald Hicks wrote: With the current hack^Wmethod used by make release we are required to add elements to a shell script which deletes items from the GENERIC configuration to create BOOTMFS. If my proposition holds water we can do away with the linkage to GENERIC in favor of a statically defined and minimal BOOTMFS kernel. Didn't Poul just post on -hackers about some patches from some W Gerald Hicks guy (whoever that is ;^)) that objcopy's the MFS image into the binary, instead of using the current hack^Wmethod? You could always as you to send them to you so that you could get you to commit them for him. I know that put you in the position of middleman, but still... 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: bdwrite: buffer is not busy
I've been having inexplicable crashes for a while and finally got around to getting a debug kernel and checking out what's going on, so here goes (apologies for the ^M's and all, I scripted a gdb session and that's what I got...): panic: bdwrite: buffer is not busy panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc1ca20f4 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d9b60 stack pointer = 0x10:0xd1e20a7c frame pointer = 0x10:0xd1e20a94 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 = 828 (smtpd) trap number = 12 panic: page fault syncing disks... panic: bdwrite: buffer is not busy Uptime: 43m45s Dumping 256 MB ata0: resetting devices .. done 16 32[CTRL-C to abort] 48[CTRL-C to abort] 64 80 96 112 128 144[CTRL-C to abort] 160[CTRL-C to abort] 176 192 208 224 240 --- #0 0x in ?? () (kgdb) hw where #0 0x in ?? () (kgdb) quit I've caught a few of these by hand while working in the console before, but thought they'd been resolved until now. FreeBSD CPE0030ab0ef2bb.cpe.net.cable.rogers.com 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Sun Jul 14 20:26:50 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARCADIA i386 The sources are from about 1800 EST, July 14. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
