Re: PCI-CardBus bridge + PCMCIA Lucent WaveLAN IEEE troubles
On Fri, 14 Apr 2000, Warner Losh wrote: > : The situation is interesting - when I remove /dev/card1,2,3, pccardd > : get started, ifconfig wi0 works, but on any xmit - ping, etc.. > : I've got: > : > : wi0: xmit failed > : wi0: tx buffer allocation failed > : wi0: device timeout > : > : and pccardd didn't catch pccard events - removing and inserting cards... > > You have interrupt problems. Don't share with anything else. Don't > use interrupts of *ANY* other hardware in your system *AT*ALL*. I have only 11 & 15 IRQ used - for Bridge and for NIC Thanks alot, but your input didn't help... I tried different IRQs for pccard, polling and "normal" (have irq) mode, but no success. I have only ONE pccard, but why kernel thinks that I have two and they are inserted? (see at the bottom of dmesg) Maybe problem in init of TI chip? My full dmesg: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Sat Apr 15 10:45:51 GMT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/SETUP.5 Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300683001 Hz CPU: Pentium II/Pentium II Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping = 4 Features=0x80f9ff real memory = 33554432 (32768K bytes) config> q avail memory = 29634560 (28940K bytes) Preloaded elf kernel "kernel" at 0xc031e000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc031e09c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 2.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 pci0: at 2.2 chip1: port 0x5000-0x500f at device 2.3 on pci0 ed0: port 0xe400-0xe41f irq 15 at device 15.0 on pci0 ed0: supplying EUI64: 00:00:21:ff:fe:d7:67:6e ed0: address 00:00:21:d7:67:6e, type NE2000 (16 bit) pcic-pci0: mem 0xea00-0xea000fff irq 11 at device 16.0 on pci0 pcic-pci0: TI12XX PCI Config Reg: [pwr save][pci only] pcic-pci1: mem 0xea004000-0xea004fff irq 11 at device 16.1 on pci0 pcic-pci1: TI12XX PCI Config Reg: [pwr save][pci only] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> pcic0: at port 0x3e0 iomem 0xd irq 11 on isa0 pcic0: management irq 11 ^^ - polling mode for pcic0 didn't solve the problem pccard0: on pcic0 pccard1: on pcic0 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 ad0: 4112MB [8912/15/63] at ata0-master using UDMA33 Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 ^ why? ed0: starting DAD for fe80:0001::0200:21ff:fed7:676e ed0: DAD complete for fe80:0001::0200:21ff:fed7:676e - no duplicates found wi0: at port 0x240-0x27f irq 9 slot 0 on pccard0 ^^ ^^^ I've tried 0x100,0x300,etc and 5,7,10 wi0: Ethernet address: 00:60:1d:f6:cc:5d wi0: tx buffer allocation failed wi0: starting DAD for fe80:000b::0260:1dff:fef6:cc5d wi0: xmit failed wi0: DAD complete for fe80:000b::0260:1dff:fef6:cc5d - no duplicates found wi0: device timeout wi0: tx buffer allocation failed wi0: xmit failed wi0: device timeout wi0: tx buffer allocation failed Michael Vasilneko To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libgcc
When does subj links with the executables? I have many problems linking new KDE, because it uses service function from this library, and i suspect that libgcc.a is not linked by default. :( Should it or i have to point it (?) by hands? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libgcc
On Sat, Apr 15, 2000 at 11:26:44AM +0400, Ilmar S. Habibulin wrote: > When does subj links with the executables? When using the ``cc'' or ``c++'' front ends libgcc.a is automatically linked in. Use ``cc -v'' to see this happening. > I have many problems linking new KDE, because it uses service function > from this library, and i suspect that libgcc.a is not linked by > default. :( Should it or i have to point it (?) by hands? Adding "CFLAGS+= -v" to your /etc/make.conf might help you in finding the problem. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New bktr driver for FreebSD/Alpha (bt848/bt878)
I've committed my changes to make the bktr Bt848/bt878 driver compile on the Alpha to -current. Please can someone test it on an experimental Alpha box. It may panic your machine. (this is quite possible!!!) so please only do this on a machine you are willing to experiment with. Please email me any feedback. I have no Alpha hardware so I've no idea how well this will work. Roger -- Roger Hardiman Strathclyde Uni Telepresence Research Group, Glasgow, Scotland. http://www.telepresence.strath.ac.uk 0141 548 2897 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Geek Port crash
Bringing back a problem discussed earlier that I couldn't find a
resolution on, I'm having problems with the ppi interface blowing up the
system (CVSup'd to 4.0-CURRENT somewhere around April 3). (I just want my
dumb little 8-bit LED array to blink on and off and show no useful
information! :) )
I'll try to update tomorrow and try it again, but I get the feeling that
I'll have the same problem.
Crash dumps and kernels available upon request - I don't know enough about
the irq handling to even begin to look at this one...
The crash:
hawk:/home/mike# ./geekport
panic: nexus_setup_intr: NULL irq resource!
syncing disks... 6 6
done
Uptime: 3m28s
dumping to dev #ad/0x20001, offset 73728
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1 succeeded
Automatic reboot in 15 seconds - press a key on the console to abort
...The core dump messages:
checking for core dump...savecore: reboot after panic: nexus_setup_intr:
NULL irq resource!
Apr 14 22:59:29 hawk savecore: reboot after panic: nexus_setup_intr: NULL
irq resource!
savecore: system went down at Frfi Apr 14 22:57:0x2 2000
savecore: /var/crash/bounds: No such file or directory
savecore: writing core to /var/crash/vmcore.0
savecore: writing kernel to /var/crash/kernel.0
The code which triggers this:
#include
#include
#include
#include
#include
#include
// #include
// ^^^ will not compile if this is in there!
#define PPIDEV "/dev/ppi0"
main()
{
int x, y, fd;
fd = open(PPIDEV, O_RDWR);
if (fd < 0) {
printf("can't open %s\n", PPIDEV);
exit(1);
}
for(;;) {
for (x=0; x<=255; x++) {
y = ioctl(fd, PPISDATA, &x);
sleep(1);
}
}
}
--Thanks - Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: PCI-CardBus bridge + PCMCIA Lucent WaveLAN IEEE troubles
> : Are there any datasheets available for this bridge ? > > Yes. However, I've had several reports of the lucent wavelan bridge > working flawlessly. I recall (but might be wrong) that most if not all sucess stories are on notebooks with the TI-1225 on the motherboard. Maybe the notebook bios do something more than isn't done on a normal pc? John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI-CardBus bridge + PCMCIA Lucent WaveLAN IEEE troubles
> In message <[EMAIL PROTECTED]> John Hay writes: > : This is where I'm stuck too. I think there might be some more initialization > : of the TI1225 necesary. > > I've added some init of the ti chipsets to -current. They are enough > for my TI-1221 based card to allow me to talk to the modems that I > have. Yes, that is the code I'm running. From looking at the wi driver I think our problem is even before a (non) working interrupt would come into the picture. It looks like the driver give a command to the card to allocate a transmit buffer and then it does a poll loop reading the status of the card and it is there that it timeout. Doing some manual inb()s at the port addresses of the wi card, it looks like the card is there, ie. I don't read 0xffs back, but for some reason the card does not react in the way that the driver expects. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: MLEN and crashes
On 2000-Apr-14 23:40:53 +1000, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: >In message <[EMAIL PROTECTED]>, Peter Jeremy write >s: >>Many years ago, I wrote a tool that analysed stack requirements by >>parsing the assembler output from the compiler. ... >Commit it either as a general tool or as a kernel targeted tool >under src/tools. And the faster the better :-) I'll have to see if I can still find it. In any case, it was designed to handle M68K assembler from a Microtec compiler. It would need some re-work before it could work with FreeBSD. On 2000-Apr-14 23:49:58 +1000, Thomas David Rivers <[EMAIL PROTECTED]> wrote: > How did you address recursive functions, or were they also forbidden > by design standards? They were forbidden from memory. (Which will be a nuisance here). They would show up as loops in the call graph. Even if I can't find my previous code, the design of such a tool is fairly trivial (given the assembler, or a suitably patched compiler). The first part reads the assembler: When a function is defined, you note the local framesize and keep track of other stack pushes/pops to work out total stack requirements for the function. When a function is called, you output a triplet of caller, called function and stack usage. (From memory I cheated a bit and output caller/called pairs, with a separate maximum stack used line). This information should be fairly trivially available within the compiler as an alternative. The second part reads all the output from the first part and forms a call flow graph, generating maximum stack needs from each node. The top level node(s) give you the total stack needs. One reason for splitting it into two bits is to make it easier to add manual entries for indirect function calls. (Some of this `manual' work could be partially automated). Recursive calls (which there are a fair number of in the FreeBSD kernel) aren't that easily handled and would probably entail manual (or semi-automatic) editing. I'll have a go at a more detailed design (and see if I can find or re-implement it) if no-one else has one already. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libgcc
On Sat, 15 Apr 2000, David O'Brien wrote: > On Sat, Apr 15, 2000 at 11:26:44AM +0400, Ilmar S. Habibulin wrote: > > When does subj links with the executables? > When using the ``cc'' or ``c++'' front ends libgcc.a is automatically > linked in. Use ``cc -v'' to see this happening. You mean to look at cc vertion? Yes, it is just gcc frontend or hardlink(i suppose). > > I have many problems linking new KDE, because it uses service function > > from this library, and i suspect that libgcc.a is not linked by > > default. :( Should it or i have to point it (?) by hands? > Adding "CFLAGS+= -v" to your /etc/make.conf might help you in finding the > problem. libtool prints out commands executed. And this autoconf/automake/configure stuff uses gcc and g++. I set CC,CXX and CPP variables. Now everything seem to work. Thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with MAKEDEV.
At 18:12 -0600 14/4/00, Nate Williams wrote: >[...] >You can easily run out of inodes on the roof partition. Sure, my roof leaks from time to time. But _inodes_? :-) :-) -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Thu, 13 Apr 2000, Michael Reifenberger wrote:
> Hi,
> when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
> FreeBSD -current. Kernel+mods in sync.
> Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday.
> Backtrace see crash.txt. Kernelconfig see nihil.
> Any thoughts anyone?
Yes, I've gotten these too. I really believe the assumptions the code
there makes are wrong, and I've got a patch to correct them to what I
think they are supposed to be. You've got the standard disclaimer on
the patch, though I assure you it has shown no ill effects to me, and I
noticed this bug through WINE.
I've asked Poul-Henning Kamp, who seems to also think that the code makes
wrong assumptions. I've asked Matt Dillon and gotten no reply (a month
now, at least). I've asked Alan Cox, and he'd help if we could get him
a test case so he can watch it happen himself and debug it himself.
Do you think you can find a specific set of steps for Alan to reproduce
it?
> Bye!
>
> Michael Reifenberger
> ^.*Plaut.*$, IT, R/3 Basis, GPS
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
Index: vm_object.c
===
RCS file: /usr2/ncvs/src/sys/vm/vm_object.c,v
retrieving revision 1.173
diff -u -r1.173 vm_object.c
--- vm_object.c 2000/03/26 15:20:22 1.173
+++ vm_object.c 2000/04/10 00:03:22
@@ -903,15 +903,25 @@
* Don't create the new object if the old object isn't shared.
*/
- if (source != NULL &&
- source->ref_count == 1 &&
- source->handle == NULL &&
- (source->type == OBJT_DEFAULT ||
-source->type == OBJT_SWAP))
- return;
+ if (source != NULL) {
+ if ((source->flags & OBJ_ONEMAPPING) != 0 &&
+ source->ref_count != 1)
+ printf("vm_object %p: flags %d, ref_count %d, " \
+ "type %d, handle %p\n",
+ source, source->flags, source->ref_count,
+ source->type, source->handle);
+ if ((source->flags & OBJ_ONEMAPPING) != 0 ||
+ (source->ref_count == 1 &&
+source->handle == NULL &&
+(source->type == OBJT_DEFAULT ||
+ source->type == OBJT_SWAP)))
+ return;
+ }
- KASSERT((source->flags & OBJ_ONEMAPPING) == 0,
+#if 0
+ KASSERT(source != NULL && (source->flags & OBJ_ONEMAPPING) == 0,
("vm_object_shadow: source object has OBJ_ONEMAPPING set.\n"));
+#endif
/*
* Allocate a new object with the given length
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, 15 Apr 2000, Brian Fundakowski Feldman wrote: ... > Do you think you can find a specific set of steps for Alan to reproduce > it? Not without this SAP-GUI in conjuntion with a SAP-System to connect to :-( But then it's easyly reproducable. BTW: with your patch I get on the console during a session: Something leaks, eh? vm_object 0xcb4f3720: flags 8576, ref_count 2, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 3, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 4, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 5, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 6, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 7, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 8, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 9, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 10, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 11, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 12, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 13, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 14, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 15, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 16, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 17, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 18, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 19, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 20, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 21, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 22, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 23, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 24, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 25, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 26, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 27, type 0, handle 0 vm_object 0xcb4f3720: flags 8576, ref_count 28, type 0, handle 0 Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re:cvs commit: src/sys/dev/ida ida_eisa.c
> "MD" == Matthew N Dodd <[EMAIL PROTECTED]> writes: MD> On Fri, 14 Apr 2000, Viren R.Shah wrote: >> >> mainboard0: >> eisa0: unknown card CPQ6101 (0x0e116101) at slot 5 >> ida0: at 0x6000-0x60ff, 0x6c88-0x6c9e >> ida0: irq 15 (level) on eisa0 slot 6 >> ida0: drives=1 firm_rev=1.66 >> idad0: 3002MB (6149631 sectors), blocksize=512 >> eisa0: u >> MD> Well, this isn't a problem with the IDA driver (unless its stomping on MD> something.) Maybe something else is stomping on it's memory? In the version of the IDA driver that it is currently booting with ( 4.0 -current from 03/1999, and Mark Dawson's driver), it shows ida as using "0x6000-0x6fff". While in the current version, it is shown as using "0x6000-0x60ff, 0x6c88-0x6c9e". Maybe it is using memory outside of the 2 ranges here, but within the larger block of memory used by the older driver? or the other way around -- someone else is using memory within the larger range that is also being used by ida [obviously a wild-assed guess on my part] MD> Can you boot verbose with the IDA driver kernel? Here it is: (is there a less painful way of doing this than typing in every line?) CPU: Pentium/P5 (66.66-Mhz586-class CPU) ... real memory = 16777216 (16384k) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00634000 - 0x00ff7fff, 1024 bytes (2500 pages) fb: new array size 4 avail memory = 10252288 (10012K bytes) Other BIOS signatures found: ACPI: Preloaded elf kernel "kernel" at 0xc061b000. Intel pentium detected, installing workaround for F00F bug. md0: Preloaded image 2949120 bytes at 0xc03492dc Creating DISK md0 md1: Malloc disk Creating DISK md1 Math emulator present pci_open(1): mode 1 addr port (0x0cf8) is 0x pci_open(2): mode 2 enable port (0x0cf8) is 0xff npx0: on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 128551227 bytes/sec bzero() bandwidth = 105152471 bytes/sec eisa0: on motherboard mainboard0: eisa0: unknown card CPQ6101 (0x0e116101) at slot 5 ida0: at 0x6000-0x60ff, 0x6c88-0x6c9e ida0: irq 15 (level) on eisa0 slot 6 ida0: drives=1 firm_rev=1.66 idad0: 3002MB (6149631 sectors), blocksize=512 Creating DISK id0 eisa0: [then the panic ensued...this time I couldn't even get a trace. It just kept panic'ing again] MD> Compile a kernel without the IDA driver and boot verbose. [Sorry, couldn't get a verbose boot, the buffer contained only the end of the dmesg -- lots of stuff about stuff not found and sio and my pnp modem. Here's a non-verbose boot with a kernel compiled without ida] real memory = 16777216 (16384k) avail memory = 10260480 (10020K bytes) Preloaded elf kernel "kernel" at 0xc0619000. Preloaded mfs_root "/mfsroot" at 0xc061909c. Intel pentium detected, installing workaround for F00F bug. md0: Preloaded image 2949120 bytes at 0xc0347a98 md1: Malloc disk npx0: on motherboard npx0: INT 16 interface eisa0: on motherboard mainboard0: eisa0: unknown card CPQ6101 (0x0e116101) at slot 5 eisa0: unknown card CPQ4020 (0x0e114020) at slot 6 eisa0: unknown card CPQ4410 (0x0e114410) at slot 9 isa0: on motherboard isa0: too many dependant configs (8) fdc0: at port 0x3f0-0x3f5, 0x3f7 irq 6, drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: cannot reserve I/O port range sn0 at port 0x300-0x30f irq 10 on isa0 adv1: Invalid baseport of 0x2f8 specified. Neerest valid baseport is 0x330. Failing probe. unknown0: at port 0x2f8-0x2ff irq 3 on isa0 Mounting root from ufs:/dev/md0c Here's the output from the currently working kernel on that box: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Feb 7 16:54:54 EST 1999 viren@bandersnatch:/home/current/usr/src/sys/compile/VIREN10 Calibrating clock(s) ... TSC clock: 3353 Hz, i8254 clock: 1193341 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 66655217 Hz CPU: Pentium/P5 (66.66-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x513 Stepping=3 Features=0x1bf real memory = 16777216 (16384K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002c - 0x00ffdfff, 13885440 bytes (3390 pages) config> pnp 1 0 enable os port0 0x2f8 irq0 5 config> quit avail memory = 13930496 (13604K bytes) Other BIOS signatures found: ACPI: $PnP: Preloaded elf kernel "ker
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
* Brian Fundakowski Feldman <[EMAIL PROTECTED]> [000415 07:07] wrote: > On Thu, 13 Apr 2000, Michael Reifenberger wrote: > > > Hi, > > when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic. > > FreeBSD -current. Kernel+mods in sync. > > Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday. > > Backtrace see crash.txt. Kernelconfig see nihil. > > Any thoughts anyone? > > Yes, I've gotten these too. I really believe the assumptions the code > there makes are wrong, and I've got a patch to correct them to what I > think they are supposed to be. You've got the standard disclaimer on > the patch, though I assure you it has shown no ill effects to me, and I > noticed this bug through WINE. > > I've asked Poul-Henning Kamp, who seems to also think that the code makes > wrong assumptions. I've asked Matt Dillon and gotten no reply (a month > now, at least). I've asked Alan Cox, and he'd help if we could get him > a test case so he can watch it happen himself and debug it himself. > > Do you think you can find a specific set of steps for Alan to reproduce > it? Yes, find all places where source->ref_count is incremented and check for OBJ_ONEMAPPING as well as where OBJ_ONEMAPPING is set. Then add some printfs to find the snippet that's incrementing it to complain when the OBJ_ONEMAPPING bit is set, and complain if setting OBJ_ONEMAPPING when the refcount is too high. Blotting out a KASSERT isn't the right thing to do. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/dev/ida ida_eisa.c
hello! [snipped-a-lot] i am currently building world and will be testing the driver. in about 4 - 5 hours (it's not the fastet machine ;-) i will be able to send feedback ... cheers, oliver -- "Mein Gott, es ist voller Sterne!" email: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! <- Save this lifeform ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Failed compile of ext2_alloc.c
Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert: I compiled recent (cvsup around 9:00 A.M. PDT) sources for the 5.0 kernel with and without options FFS_EXTATTR and obtained the following error message in both cases. cc -c -O -pipe -march=k6 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../gnu/ext2fs/ext2_alloc.c In file included from ../../gnu/ext2fs/ext2_alloc.c:54: ../../ufs/ufs/ufsmount.h:90: field `um_extattr' has incomplete type *** Error code 1 I have not investigated. I think this may have to do with your additions of extended attributes. Hope this helps. George Dinolt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Failed compile of ext2_alloc.c
Yup -- I neglected to update the ext2fs code (which uses UFS stuff) to include the requisite include files. Please try the attached patch against src/sys/gnu/ext2fs, and let me know if it works, and I'll go ahead and commit it. I caught the weird Coda dependancy, but guess I missed this one. On Sat, 15 Apr 2000, George W. Dinolt wrote: > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Robert: > > I compiled recent (cvsup around 9:00 A.M. PDT) sources for the 5.0 > kernel with and without > > options FFS_EXTATTR > > and obtained the following error message in both cases. > > cc -c -O -pipe -march=k6 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. > -I../../../include -D_KERNEL -include opt_global.h -elf > -mpreferred-stack-boundary=2 ../../gnu/ext2fs/ext2_alloc.c > In file included from ../../gnu/ext2fs/ext2_alloc.c:54: > ../../ufs/ufs/ufsmount.h:90: field `um_extattr' has incomplete type > *** Error code 1 > > I have not investigated. I think this may have to do with your additions > of extended attributes. > > Hope this helps. > George Dinolt > [EMAIL PROTECTED] > > > Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services Index: gnu/ext2fs/ext2_alloc.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_alloc.c,v retrieving revision 1.28 diff -u -r1.28 ext2_alloc.c --- gnu/ext2fs/ext2_alloc.c 1999/08/23 22:05:49 1.28 +++ gnu/ext2fs/ext2_alloc.c 2000/04/15 16:49:37 @@ -49,6 +49,7 @@ #include #include +#include #include #include #include Index: gnu/ext2fs/ext2_inode.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_inode.c,v retrieving revision 1.25 diff -u -r1.25 ext2_inode.c --- gnu/ext2fs/ext2_inode.c 2000/03/20 10:44:17 1.25 +++ gnu/ext2fs/ext2_inode.c 2000/04/15 16:49:37 @@ -53,6 +53,7 @@ #include #include +#include #include #include #include Index: gnu/ext2fs/ext2_linux_balloc.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_linux_balloc.c,v retrieving revision 1.11 diff -u -r1.11 ext2_linux_balloc.c --- gnu/ext2fs/ext2_linux_balloc.c 1999/02/25 15:54:05 1.11 +++ gnu/ext2fs/ext2_linux_balloc.c 2000/04/15 16:49:38 @@ -33,6 +33,7 @@ #include #include +#include #include #include #include Index: gnu/ext2fs/ext2_linux_ialloc.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_linux_ialloc.c,v retrieving revision 1.13 diff -u -r1.13 ext2_linux_ialloc.c --- gnu/ext2fs/ext2_linux_ialloc.c 1999/01/27 21:49:53 1.13 +++ gnu/ext2fs/ext2_linux_ialloc.c 2000/04/15 16:49:39 @@ -34,6 +34,7 @@ #include #include +#include #include #include #include Index: gnu/ext2fs/ext2_lookup.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_lookup.c,v retrieving revision 1.22 diff -u -r1.22 ext2_lookup.c --- gnu/ext2fs/ext2_lookup.c2000/03/20 11:28:36 1.22 +++ gnu/ext2fs/ext2_lookup.c2000/04/15 16:49:39 @@ -57,6 +57,7 @@ #include #include +#include #include #include #include Index: gnu/ext2fs/ext2_vfsops.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_vfsops.c,v retrieving revision 1.63 diff -u -r1.63 ext2_vfsops.c --- gnu/ext2fs/ext2_vfsops.c2000/03/09 05:21:10 1.63 +++ gnu/ext2fs/ext2_vfsops.c2000/04/15 16:49:41 @@ -56,6 +56,7 @@ #include #include +#include #include #include #include Index: gnu/ext2fs/ext2_vnops.c === RCS file: /home/ncvs/src/sys/gnu/ext2fs/ext2_vnops.c,v retrieving revision 1.51 diff -u -r1.51 ext2_vnops.c --- gnu/ext2fs/ext2_vnops.c 2000/03/03 08:00:27 1.51 +++ gnu/ext2fs/ext2_vnops.c 2000/04/15 16:49:42 @@ -68,6 +68,7 @@ #include #include +#include #include #include #include
Re: Failed compile of ext2_alloc.c
Since it appears to work for me, I'm going to go ahead and commit the patch before too many other people run into this. Please let me know if you have further problems and I'll get them fixed up ASAP. On Sat, 15 Apr 2000, George W. Dinolt wrote: > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Robert: > > I compiled recent (cvsup around 9:00 A.M. PDT) sources for the 5.0 > kernel with and without > > options FFS_EXTATTR > > and obtained the following error message in both cases. > > cc -c -O -pipe -march=k6 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. > -I../../../include -D_KERNEL -include opt_global.h -elf > -mpreferred-stack-boundary=2 ../../gnu/ext2fs/ext2_alloc.c > In file included from ../../gnu/ext2fs/ext2_alloc.c:54: > ../../ufs/ufs/ufsmount.h:90: field `um_extattr' has incomplete type > *** Error code 1 > > I have not investigated. I think this may have to do with your additions > of extended attributes. > > Hope this helps. > George Dinolt > [EMAIL PROTECTED] > > > Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, 15 Apr 2000, Alfred Perlstein wrote: > Yes, find all places where source->ref_count is incremented and check > for OBJ_ONEMAPPING as well as where OBJ_ONEMAPPING is set. > > Then add some printfs to find the snippet that's incrementing it > to complain when the OBJ_ONEMAPPING bit is set, and complain if > setting OBJ_ONEMAPPING when the refcount is too high. > > Blotting out a KASSERT isn't the right thing to do. Well, first the question must be answered, in an absolute yes or no: is it wrong in the first place to have OBJ_ONEMAPPING set with a ref_count of more than 1? I'd accept an authoritative answer about this from alc, dillon, dyson, or luoqi, who are all very familiar with the new VM. > -- > -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] > "I have the heart of a child; I keep it in a jar on my desk." -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI-CardBus bridge + PCMCIA Lucent WaveLAN IEEE troubles
In message <[EMAIL PROTECTED]> Michael Vasilenko writes: : I have only 11 & 15 IRQ used - for Bridge and for NIC OK. : I have only ONE pccard, but why kernel thinks that I have two and : they are inserted? (see at the bottom of dmesg) : Maybe problem in init of TI chip? Likely. That's a problem. : pcic0: at port 0x3e0 iomem 0xd irq 11 on isa0 : pcic0: management irq 11 : ^^ - polling mode for pcic0 didn't solve the problem ok. : pccard: card inserted, slot 1 : ^ : why? bug? : ed0: starting DAD for fe80:0001::0200:21ff:fed7:676e : ed0: DAD complete for fe80:0001::0200:21ff:fed7:676e - no duplicates found : wi0: at port 0x240-0x27f irq 9 slot 0 on pccard0 : ^^ ^^^ :I've tried 0x100,0x300,etc and 5,7,10 ok. I'm not sure what's going on here... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, 15 Apr 2000, Alfred Perlstein wrote: > Yes, find all places where source->ref_count is incremented and check > for OBJ_ONEMAPPING as well as where OBJ_ONEMAPPING is set. > > Then add some printfs to find the snippet that's incrementing it > to complain when the OBJ_ONEMAPPING bit is set, and complain if > setting OBJ_ONEMAPPING when the refcount is too high. Further elaboration: there is an assumption that it is wrong for OBJ_ONEMAPPING to be set but not when ref_count > 1. This assumption is defeated in the multiple test cases we can find. It seems that in the test cases, the common problem is with (I think mmap()d) memory across multiple processes that _share_ _a_VM_space_! It seems like what's happening is that the ref_count is increased to reflect that each process has a hold of this object, which may or may not be correct, and when that object is faulted on, the code panics because it assumes that OBJ_ONEMAPPING means that there's only one mapping of the object, but there are multiple references and so it panics. The question is not just "why" a OBJ_ONEMAPPING object has a ref_count > 1, it's whether or not that is correct WRT multiple, shared-VM processes. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
:On Thu, 13 Apr 2000, Michael Reifenberger wrote:
:
:> Hi,
:> when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
:> FreeBSD -current. Kernel+mods in sync.
:> Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday.
:> Backtrace see crash.txt. Kernelconfig see nihil.
:> Any thoughts anyone?
:
:Yes, I've gotten these too. I really believe the assumptions the code
:there makes are wrong, and I've got a patch to correct them to what I
:think they are supposed to be. You've got the standard disclaimer on
:the patch, though I assure you it has shown no ill effects to me, and I
:noticed this bug through WINE.
:
:I've asked Poul-Henning Kamp, who seems to also think that the code makes
:wrong assumptions. I've asked Matt Dillon and gotten no reply (a month
:now, at least). I've asked Alan Cox, and he'd help if we could get him
:a test case so he can watch it happen himself and debug it himself.
:
:Do you think you can find a specific set of steps for Alan to reproduce
:it?
:
:> Bye!
:>
:> Michael Reifenberger
:> ^.*Plaut.*$, IT, R/3 Basis, GPS
:
:--
: Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
: [EMAIL PROTECTED]`--'
Oh, sorry about that. I've run out of time and I have to take a
chopper to my email. Sometimes I chop out too much.
vm_object_shadow() is used to shadow VM objects when a write fault
occurs, and when forking (to avoid early copying of the vm_object's).
Hmm. Lets see. Well, I'd say the original code is obviously wrong.
You CAN have a ref_count > 1 and still have OBJ_ONEMAPPING set. I
remember Alan and I discovering that case last year as we were fixing
up the vm_object stuff. Basically, the ref_count can be temporarily
bumped with OBJ_ONEMAPPING still set.
Here's an associated piece of code to look at. Line 2133 of
vm_map.c (in vmspace_fork()). Here the vmspace_fork() code is
trying to force the creation of a shadow object which it then
intends to close. It is bumping the ref_count to 'ensure' this.
So your change will break this piece of code.
/*
* Add the reference before calling vm_object_shadow
* to insure that a shadow object is created.
*/
vm_object_reference(object);
if (old_entry->eflags & MAP_ENTRY_NEEDS_COPY) {
vm_object_shadow(&old_entry->object.vm_object,
&old_entry->offset,
atop(old_entry->end - old_entry->start))
;
old_entry->eflags &= ~MAP_ENTRY_NEEDS_COPY;
object = old_entry->object.vm_object;
}
vm_object_clear_flag(object, OBJ_ONEMAPPING);
I think the solution is to cear OBJ_ONEMAPPING before calling
vm_object_shadow() in vm_map.c, PLUS do your patch. I've included
my version below (untested).
Re: The other person's comment about a possible reference count leak.
I do not believe there is any reference count leak, the reference count
was being bumped due to the forks and the shadows causing fragmentation
of the original object.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
Index: vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.187
diff -u -r1.187 vm_map.c
--- vm_map.c2000/02/28 04:10:35 1.187
+++ vm_map.c2000/04/15 18:02:06
@@ -2119,10 +2119,14 @@
}
/*
-* Add the reference before calling vm_object_shadow
-* to insure that a shadow object is created.
+* Clear OBJ_ONEMAPPING before calling vm_object_shadow
+* to ensure that a shadow object is created. Add a
+* reference to cover the new vm_map_entry being
+* associated with the object.
*/
vm_object_reference(object);
+ vm_object_clear_flag(object, OBJ_ONEMAPPING);
+
if (old_entry->eflags & MAP_ENTRY_NEEDS_COPY) {
vm_object_shadow(&old_entry->object.vm_object,
&old_entry->offset,
@@ -2130,7 +2134,6 @@
old_entry->eflags &= ~MAP_ENTRY_NEEDS_COPY;
object = old_entry->object.vm_object;
}
- vm_object_clear_flag(object, OBJ_ONEMAPPING);
/*
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
:Further elaboration:
:
:there is an assumption that it is wrong for OBJ_ONEMAPPING to be set but
:not when ref_count > 1. This assumption is defeated in the multiple test
:cases we can find. It seems that in the test cases, the common problem
:is with (I think mmap()d) memory across multiple processes that _share_
:_a_VM_space_! It seems like what's happening is that the ref_count is
:increased to reflect that each process has a hold of this object, which
:may or may not be correct, and when that object is faulted on, the code
:panics because it assumes that OBJ_ONEMAPPING means that there's only
:one mapping of the object, but there are multiple references and so it
:panics.
:
:The question is not just "why" a OBJ_ONEMAPPING object has a ref_count > 1,
:it's whether or not that is correct WRT multiple, shared-VM processes.
:
:--
: Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
: [EMAIL PROTECTED]`--'
Originally (3.x and before), the OBJ_ONEMAPPING was not set entirely
properly and people had hacked the code to use ref_count in combination
with it.
Alan and I fixed this all last year, but obviously didn't fix all the
cases.
Now OBJ_ONEMAPPING is the true indicator of there being a single mapping,
and ref_count is irrelevant. Or supposed to be irrelevant, anyway.
My patch was incorrect. Or, I should say, your original patch is
incorrect. I don't think it's legal to put in the
(source->flags & OBJ_ONEMAPPING) test that you added in vm_object.c,
because OBJ_ONEMAPPING should be clear prior to calling
vm_object_shadow anyway (or there's no point in shadowing the object
in the first place!).
My patch to vm_map.c should do the trick. But there is one more case
we have to consider that I am not sure about, and that is the two
calls to vm_object_shadow() in vm_map_pageable() (vm_map.c line 1356).
vm_map_pageable() is used byvslock/vsunlock, which is used by the
sysctl code (???), and used in kmem_alloc() (where OBJ_ONEMAPPING is
not set anyway).
I think we may have a case where sysctl() operates on a shared
address space that may still panic.
Here is a new patch. Please try it (and get rid of any prior patches
to vm_object.c before applying this one).
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
Index: vm_map.c
===
RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
retrieving revision 1.187
diff -u -r1.187 vm_map.c
--- vm_map.c2000/02/28 04:10:35 1.187
+++ vm_map.c2000/04/15 18:02:06
@@ -2119,10 +2119,14 @@
}
/*
-* Add the reference before calling vm_object_shadow
-* to insure that a shadow object is created.
+* Clear OBJ_ONEMAPPING before calling vm_object_shadow
+* to ensure that a shadow object is created. Add a
+* reference to cover the new vm_map_entry being
+* associated with the object.
*/
vm_object_reference(object);
+ vm_object_clear_flag(object, OBJ_ONEMAPPING);
+
if (old_entry->eflags & MAP_ENTRY_NEEDS_COPY) {
vm_object_shadow(&old_entry->object.vm_object,
&old_entry->offset,
@@ -2130,7 +2134,6 @@
old_entry->eflags &= ~MAP_ENTRY_NEEDS_COPY;
object = old_entry->object.vm_object;
}
- vm_object_clear_flag(object, OBJ_ONEMAPPING);
/*
* Clone the entry, referencing the shared object.
Index: vm_object.c
===
RCS file: /home/ncvs/src/sys/vm/vm_object.c,v
retrieving revision 1.171.2.1
diff -u -r1.171.2.1 vm_object.c
--- vm_object.c 2000/03/17 10:47:35 1.171.2.1
+++ vm_object.c 2000/04/15 18:13:58
@@ -900,7 +900,13 @@
source = *object;
/*
-* Don't create the new object if the old object isn't shared.
+* If the old object is not shared we may be able to simply use it
+* as the shadow rather then have to create a new object. Only
+* objects that we can guarentee this case can be optimized - that is,
+* only objects with no handles that other processes can get a hold
+* of which are otherwise unassociated, have only one mapping, and
+* only one reference count. XXX do we need the reference count check
+* any more? XXX
*/
if (source != NULL &&
To Unsubscribe: send ma
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
:Well, first the question must be answered, in an absolute yes or no: :is it wrong in the first place to have OBJ_ONEMAPPING set with a ref_count :of more than 1? I'd accept an authoritative answer about this from :alc, dillon, dyson, or luoqi, who are all very familiar with the new :VM. :-- : Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / : [EMAIL PROTECTED]`--' It is totally legal for OBJ_ONEMAPPING to be set even if the ref_count is greater then 1. The ref_count has no bearing on the shareability of the object any more. The tests were there before due to all sorts of crud that had been hacked in in the 2.2.x and 3.x era to get around serious bugs in the OBJ_ONEMAPPING flag and elsewhere in the VM system. Note that the ref_count == 1 test in the vm_object_shadow optimization should be left intact. This optimization requires a much stricter set of tests because we do not want to assume sharability of an object if someone else (the 'else' being 'someone unknown to us') has a reference on it, even if OBJ_ONEMAPPING is set. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Failed compile of ext2_alloc.c
Robert: Re the supplied patches. I applied them and the kernel compiled, loaded and ran. There seem to be some problems with the modules I use for my ethernet cards so I was not able to give it a "thorough" testing. I don;t think the module issues relate to the file system. I seemed to have hit an inconsistency between the modules (fxp and dc) and kernel as part of the CVS updates I have been doing. .I hope to investigate more later. Regards, George Dinolt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
* Matthew Dillon <[EMAIL PROTECTED]> [000415 11:32] wrote:
>
> :On Thu, 13 Apr 2000, Michael Reifenberger wrote:
> :
> :> Hi,
> :> when using a linux java app (SAP PlatinGUI 46Cb2) I get the above panic.
> :> FreeBSD -current. Kernel+mods in sync.
> :> Linux from ports. Linux-Java-JDK 1.2.2 from blackdown as of yesterday.
> :> Backtrace see crash.txt. Kernelconfig see nihil.
> :> Any thoughts anyone?
> :
> :Yes, I've gotten these too. I really believe the assumptions the code
> :there makes are wrong, and I've got a patch to correct them to what I
> :think they are supposed to be. You've got the standard disclaimer on
> :the patch, though I assure you it has shown no ill effects to me, and I
> :noticed this bug through WINE.
> :
> :I've asked Poul-Henning Kamp, who seems to also think that the code makes
> :wrong assumptions. I've asked Matt Dillon and gotten no reply (a month
> :now, at least). I've asked Alan Cox, and he'd help if we could get him
> :a test case so he can watch it happen himself and debug it himself.
> :
> :Do you think you can find a specific set of steps for Alan to reproduce
> :it?
> :
> :> Bye!
> :>
> :> Michael Reifenberger
> :> ^.*Plaut.*$, IT, R/3 Basis, GPS
> :
> :--
> : Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
> : [EMAIL PROTECTED]`--'
>
> Oh, sorry about that. I've run out of time and I have to take a
> chopper to my email. Sometimes I chop out too much.
>
> vm_object_shadow() is used to shadow VM objects when a write fault
> occurs, and when forking (to avoid early copying of the vm_object's).
>
> Hmm. Lets see. Well, I'd say the original code is obviously wrong.
> You CAN have a ref_count > 1 and still have OBJ_ONEMAPPING set. I
> remember Alan and I discovering that case last year as we were fixing
> up the vm_object stuff. Basically, the ref_count can be temporarily
> bumped with OBJ_ONEMAPPING still set.
>
> Here's an associated piece of code to look at. Line 2133 of
> vm_map.c (in vmspace_fork()). Here the vmspace_fork() code is
> trying to force the creation of a shadow object which it then
> intends to close. It is bumping the ref_count to 'ensure' this.
> So your change will break this piece of code.
>
> /*
> * Add the reference before calling vm_object_shadow
> * to insure that a shadow object is created.
> */
> vm_object_reference(object);
> if (old_entry->eflags & MAP_ENTRY_NEEDS_COPY) {
> vm_object_shadow(&old_entry->object.vm_object,
> &old_entry->offset,
> atop(old_entry->end - old_entry->start))
> ;
> old_entry->eflags &= ~MAP_ENTRY_NEEDS_COPY;
> object = old_entry->object.vm_object;
> }
> vm_object_clear_flag(object, OBJ_ONEMAPPING);
>
> I think the solution is to cear OBJ_ONEMAPPING before calling
> vm_object_shadow() in vm_map.c, PLUS do your patch. I've included
> my version below (untested).
I really don't like this, what's the point of having a "helper"
function vm_object_reference(), if it doesn't do all the required
work (vm_object_clear_flag())? This adds unneeded complexity to the
caller.
Is there a good reason for not having the vm_object_clear_flag() in
vm_object_reference()?
>
> Re: The other person's comment about a possible reference count leak.
> I do not believe there is any reference count leak, the reference count
> was being bumped due to the forks and the shadows causing fragmentation
> of the original object.
A reference count leak did occur, ref_count was bumped without other
sanity flags being cleared, the code makes it easy to shoot yourself
in the foot.
-Alfred
> Index: vm_map.c
> ===
> RCS file: /home/ncvs/src/sys/vm/vm_map.c,v
> retrieving revision 1.187
> diff -u -r1.187 vm_map.c
> --- vm_map.c 2000/02/28 04:10:35 1.187
> +++ vm_map.c 2000/04/15 18:02:06
> @@ -2119,10 +2119,14 @@
> }
>
> /*
> - * Add the reference before calling vm_object_shadow
> - * to insure that a shadow object is created.
> + * Clear OBJ_ONEMAPPING before calling vm_object_shadow
> + * to ensure that a shadow object is created. Add a
> + * reference to cover the new vm_map_entry being
> + * associated with the object.
>*/
> vm_object_reference(object);
> + vm_object_clear_flag(object, OBJ_ONEMAPPING);
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, Apr 15, 2000 at 11:23:11AM -0700, Matthew Dillon wrote: > :Well, first the question must be answered, in an absolute yes or no: > :is it wrong in the first place to have OBJ_ONEMAPPING set with a ref_count > :of more than 1? I'd accept an authoritative answer about this from > :alc, dillon, dyson, or luoqi, who are all very familiar with the new > :VM. > :-- > : Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / > : [EMAIL PROTECTED]`--' > > It is totally legal for OBJ_ONEMAPPING to be set even if the ref_count > is greater then 1. Agreed. OBJ_ONEMAPPING actually means that *each page* within the object is mapped at most once. The object itself may be mapped many times, as long as the previous rule isn't violated. In other words, none of the mappings map an overlapping set of pages. > ... The ref_count has no bearing on the shareability > of the object any more. The tests were there before due to all sorts > of crud that had been hacked in in the 2.2.x and 3.x era to get around > serious bugs in the OBJ_ONEMAPPING flag and elsewhere in the VM system. > > Note that the ref_count == 1 test in the vm_object_shadow optimization > should be left intact. This optimization requires a much stricter set > of tests because we do not want to assume sharability of an object > if someone else (the 'else' being 'someone unknown to us') has a reference > on it, even if OBJ_ONEMAPPING is set. > Here's what troubles me about the state of the OBJ_ONEMAPPING management code: When we clear the OBJ_ONEMAPPING attribute on an object, we don't touch any of its backing objects. Specifically, we don't guarantee that they don't have OBJ_ONEMAPPING set. I think we should, if only because it makes reasoning about the system's behavior a lot easier. If we cleared OBJ_ONEMAPPING recursively, then the rationale for this assertion would go away. Brian, if you'd like to try this, I'll be happy to review it. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI-CardBus bridge + PCMCIA Lucent WaveLAN IEEE troubles
In message <[EMAIL PROTECTED]> John Hay writes: : I recall (but might be wrong) that most if not all sucess stories are : on notebooks with the TI-1225 on the motherboard. Maybe the notebook : bios do something more than isn't done on a normal pc? That's entirely possible. All notebook BIOSes that I've looked at try to initialize the cardbus bridge into some known state. Many of the initialize it into a state very compatible with FreeBSD's assumptions (sometimes with some setup help from the user). Some don't. Nearly none of the desktops do the right thing as far as initialization of the cards goes, so as we see more card bus bridges we have to get smarters. On the laptops as well, one can add a TI-950 or equivalent part wired to the south bridge (well, the pci isa bridge which I think is usually called the south bridge) which allows one to do serial interrupt ISA routing over the PCI bus. I'm not sure how many desktops, if any, do this sort of thing. I just now found the datasheet from TI and have started looking at it. It does support some kind of PCI standard on the topic, but I've not looked into enough to know how standard this standard is. Briefly, it allows one to route any IRQ or PCI interrupt using a serial protocol for the interrupt. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI-CardBus bridge + PCMCIA Lucent WaveLAN IEEE troubles
In message <[EMAIL PROTECTED]> John Hay writes: : our problem is even before a (non) working interrupt would come into the : picture. I'd have to say that based on the evidence so far, that the interrupts aren't getting routined correctly, or that there's an interrupt conflict. This is almost certainly at the cardbus bridge layer, even though I don't want it to be :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Netscape 6 Linux pre-release, got it going.
On Fri, 14 Apr 2000, Donn Miller wrote: > Over the past month, in -current, I've had weird problems with > Mozilla. The message I'm seeing on stdout is Perhaps you'd have benn luck taking this bug report to the mozilla developers? I don't know there's anyone on this list who is truly familiar with the mozilla code and able to help you. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, 15 Apr 2000, Matthew Dillon wrote: > [explanation] > > Here is a new patch. Please try it (and get rid of any prior patches > to vm_object.c before applying this one). > Thanks for the reply :) What you say makes sense, so I'll try out this patch as soon as I work out a way to get my machine to panic on demand, as I'm also trying to track down an issue with the machine responding to net interrupts and I can't tell if it responds to anything else, but certainly doesn't function much at all. I still have my test case (a 3/15 CVS checkout of Wine) lying around, so I'll be able to definitely test it :) > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, 15 Apr 2000, Alan Cox wrote: > > It is totally legal for OBJ_ONEMAPPING to be set even if the ref_count > > is greater then 1. > > Agreed. OBJ_ONEMAPPING actually means that *each page* within the object > is mapped at most once. The object itself may be mapped many times, > as long as the previous rule isn't violated. In other words, none > of the mappings map an overlapping set of pages. Alright, this makes sense to me. > > ... The ref_count has no bearing on the shareability > > of the object any more. The tests were there before due to all sorts > > of crud that had been hacked in in the 2.2.x and 3.x era to get around > > serious bugs in the OBJ_ONEMAPPING flag and elsewhere in the VM system. > > > > Note that the ref_count == 1 test in the vm_object_shadow optimization > > should be left intact. This optimization requires a much stricter set > > of tests because we do not want to assume sharability of an object > > if someone else (the 'else' being 'someone unknown to us') has a reference > > on it, even if OBJ_ONEMAPPING is set. > > > > Here's what troubles me about the state of the OBJ_ONEMAPPING management > code: When we clear the OBJ_ONEMAPPING attribute on an object, we don't > touch any of its backing objects. Specifically, we don't guarantee > that they don't have OBJ_ONEMAPPING set. I think we should, if only > because it makes reasoning about the system's behavior a lot easier. > > If we cleared OBJ_ONEMAPPING recursively, then the rationale for > this assertion would go away. I'm still trying to understand this: if you know that the object may have pages mapped elsewhere, the backing objects recursively inherit the assumption that it may have parts mapped elsewhere? So, when you set OBJ_ONEMAPPING, should you check upward recursively to check if those objects can have OBJ_ONEMAPPING set? I assume that you mean that a backing object itself should have OBJ_ONEMAPPING cleared if any of the children have it cleared. > Brian, if you'd like to try this, I'll be happy to review it. I'm going to research the VM a bit more now that you and Matt have gotten me on track again, and soon wouldn't mind doing that :) > Alan -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, 15 Apr 2000, Matthew Dillon wrote: > Note that the ref_count == 1 test in the vm_object_shadow optimization > should be left intact. This optimization requires a much stricter set > of tests because we do not want to assume sharability of an object > if someone else (the 'else' being 'someone unknown to us') has a reference > on it, even if OBJ_ONEMAPPING is set. The KASSERT is broken in another way, BTW: it has undefined (read: panic before the test even occurs) results if source is NULL, which vm_object_shadow otherwise handles. I don't know why it's never been tripped on, though... > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with MAKEDEV.
On Fri, Apr 14, 2000 at 11:41:55AM +0100, Ashley Penney wrote: > When booting up I noticed the block device warning message. I > did some investigation and discovered that some ad4/ad5 devices > were still block ones. It seems that the MAKEDEV script only > makes up to ad3, but my disks are on ad4/ad5 (ATA-66, Abit BP6). /dev/MAKEDEV.local N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, Apr 15, 2000 at 06:12:22PM -0400, Brian Fundakowski Feldman wrote: > On Sat, 15 Apr 2000, Matthew Dillon wrote: > > > Note that the ref_count == 1 test in the vm_object_shadow optimization > > should be left intact. This optimization requires a much stricter set > > of tests because we do not want to assume sharability of an object > > if someone else (the 'else' being 'someone unknown to us') has a reference > > on it, even if OBJ_ONEMAPPING is set. > > The KASSERT is broken in another way, BTW: it has undefined (read: > panic before the test even occurs) results if source is NULL, which > vm_object_shadow otherwise handles. I don't know why it's never been > tripped on, though... > Other parts of the VM insure that we never try to create a shadow object for a non-existant backing object. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, Apr 15, 2000 at 06:09:56PM -0400, Brian Fundakowski Feldman wrote: > > I'm still trying to understand this: if you know that the object may > have pages mapped elsewhere, the backing objects recursively inherit > the assumption that it may have parts mapped elsewhere? Umm, just to be clear, it's not that the object has pages mapped elsewhere, it's that one (or more) pages in the object have two or more mappings. In other words, the same physical page is mapped twice. It's okay for an object to have multiple mappings (and thus ref_count > 1) and have OBJ_ONEMAPPING set if all of these mappings map disjoint sets of pages. (This is what's happening when the assertion gets mistriggered.) So, OBJ_ONEMAPPING gets cleared whenever it becomes possible for the same physical page to get mapped twice. (In other words, it happens before the mapping is actually created, e.g., from vm_map_copy_entry() that gets called on a fork.) Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level object, and none of its backing objects. Nothing guarantees that these backing objects have OBJ_ONEMAPPING cleared. The page that we're "double" mapping may, however, reside in one of its backing objects. This is bad. > ... So, when you > set OBJ_ONEMAPPING, should you check upward recursively to check if > those objects can have OBJ_ONEMAPPING set? No. When you clear OBJ_ONEMAPPING, you should clear OBJ_ONEMAPPING on all of its backing objects. You can only set OBJ_ONEMAPPING under limited circumstances where you can prove that no page within an object has two or more mappings, e.g., the object's ref_count == 1. > ... I assume that you mean that > a backing object itself should have OBJ_ONEMAPPING cleared if any of > the children have it cleared. > No. backing object == child. Stepping back from the details, keep in mind the following: OBJ_ONEMAPPING is an optimization. If you clear it when it could be set, nothing breaks. (The worst case is that we don't free up swap space as quickly. An entire chain of objects has to disappear before we can reclaim the swap.) On the other hand, if you set OBJ_ONEMAPPING when it shouldn't be set, you break things badly. (Go back and look at the mailing lists when John first introduced this code.) Alan P.S. This is one area where UVM has the advantage. They have per-page ref counts in their vm objects, and not just vm object granularity ref counts. Thus OBJ_ONEMAPPING isn't necessary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
:Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level :object, and none of its backing objects. Nothing guarantees that these :backing objects have OBJ_ONEMAPPING cleared. The page that we're "double" :mapping may, however, reside in one of its backing objects. This is :bad. I don't think this is an issue. The only double-mapped pages we care about are those at the top-level (vm_object's connected directly to a vm_map_entry). This is because these are the only pages effected by write-faults and copy-on-write issues. For example, if you dirty a page that is mapped privately the system must copy-on-write the page. More importantly, if you fork() and either parent or child dirties what is now a shared page, they need to copy on write and the other process cannot see that change. OBJ_ONEMAPPING is an optimization that allows a process to dirty an anonymous (not vnode-backed) page without doing a copy-on-write in the case where that process is the ONLY process mapping the page. Copy-on-write is an issue that only effects the top level object. So we shouldn't care whether OBJ_ONEMAPPING is set or cleared in deeper objects. Copying a page that was previously shared is an expensive operation not only in having to do the copy, but also in having to split the vm_map_entry and create a new holding vm_object to hold the copy. This new object must have OBJ_ONEMAPPING set so that when pages are dirtied around it, it can be pre-pended or post-pended with the new pages rather then have to create a new vm_object (and thus not be able to coalesce the associated vm_map_entry structures) every time we take a copy-on-write fault. In this respect, the OBJ_ONEMAPPING optimization is *CRITICAL* to the scaleability of our VM system. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
:Is there a good reason for not having the vm_object_clear_flag() in :vm_object_reference()? Well, yes... vm_object's are referenced for all sorts of things temporarily. Everything from a process looking one up temporarily to the swap code issuing I/O. None of these references have anything to do with OBJ_ONEMAPPING. :A reference count leak did occur, ref_count was bumped without other :sanity flags being cleared, the code makes it easy to shoot yourself :in the foot. This is not necessarily a leak. If you have discontinuous vm_map_entry structures pointing to the same vm_object, then the vm_object will have a big reference count and can still be set OBJ_ONEMAPPING. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, Apr 15, 2000 at 08:13:20PM -0700, Matthew Dillon wrote:
>
> :Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level
> :object, and none of its backing objects. Nothing guarantees that these
> :backing objects have OBJ_ONEMAPPING cleared. The page that we're "double"
> :mapping may, however, reside in one of its backing objects. This is
> :bad.
>
> I don't think this is an issue. The only double-mapped pages we care
> about are those at the top-level (vm_object's connected directly to a
> vm_map_entry). This is because these are the only pages effected by
> write-faults and copy-on-write issues.
>
I disagree. If a backing object (BO) has OBJ_ONEMAPPING set, and someone
call vm_map_delete(map, start, end) on an address space that references
BO directly, then the system will crash and burn because vm_map_delete
will (incorrectly) free physical pages:
...
pmap_remove(map->pmap, s, e);
if (object != NULL &&
object->ref_count != 1 &&
(object->flags & (OBJ_NOSPLIT|OBJ_ONEMAPPING)) == OBJ_ONEMAPPING &&
(object->type == OBJT_DEFAULT || object->type == OBJT_SWAP)) {
vm_object_collapse(object);
vm_object_page_remove(object, offidxstart, offidxend, FALSE);
^
The reason why John Dyson introduced OBJ_ONEMAPPING was so that he
could know that physical pages were unreferenced (and thus free the pages)
even though the object's ref count > 1. He was spurred on by the UVM
work, which accomplished the same thing via per-page reference counting.
> For example, if you dirty a page that is mapped privately the system must
> copy-on-write the page. More importantly, if you fork() and either parent
> or child dirties what is now a shared page, they need to copy on write
> and the other process cannot see that change. OBJ_ONEMAPPING is an
> optimization that allows a process to dirty an anonymous (not vnode-backed)
> page without doing a copy-on-write in the case where that process is
> the ONLY process mapping the page.
>
Umm, it can do this without the OBJ_ONEMAPPING attribute, because
the ref count on the object == 1. Note that the code from vm_object_shadow
doesn't even check OBJ_ONEMAPPING:
/*
* Don't create the new object if the old object isn't shared.
*/
if (source != NULL &&
source->ref_count == 1 &&
source->handle == NULL &&
(source->type == OBJT_DEFAULT ||
source->type == OBJT_SWAP))
return;
> Copy-on-write is an issue that only effects the top level object. So
> we shouldn't care whether OBJ_ONEMAPPING is set or cleared in deeper
> objects.
>
I do care, because I don't want those pages freed by a vm_map_delete.
> Copying a page that was previously shared is an expensive operation not
> only in having to do the copy, but also in having to split the vm_map_entry
> and create a new holding vm_object to hold the copy. This new object must
> have OBJ_ONEMAPPING set so that when pages are dirtied around it, it can
> be pre-pended or post-pended with the new pages rather then have to create
> a new vm_object (and thus not be able to coalesce the associated
> vm_map_entry structures) every time we take a copy-on-write fault.
>
Huh? It's always been the case that when a shadow object is created,
its size is equal to the size of the mapping. This predates the
existance of OBJ_ONEMAPPING. vm_map_lookup, where shadow objects
are normally created on COW faults, has always done:
if (fault_type & VM_PROT_WRITE) {
/*
* Make a new object, and place it in the object
* chain. Note that no new references have appeared
* -- one just moved from the map to the new
* object.
*/
if (vm_map_lock_upgrade(map))
goto RetryLookup;
vm_object_shadow(
&entry->object.vm_object,
&entry->offset,
atop(entry->end - entry->start));
^^^
so that pages can be added to the shadow object without creating
a new object.
> In this respect, the OBJ_ONEMAPPING optimization is *CRITICAL* to the
> scaleability of our VM system.
>
It's not critical. COW worked just fine (performance-wise)
before OBJ_ONEMAPPING. John Dyson introduced OBJ_ONEMAPPING
so that he could free individual pages within an object earlier,
without waiting for the entire object to be freed.
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
On Sat, Apr 15, 2000 at 08:18:01PM -0700, Matthew Dillon wrote: > :Is there a good reason for not having the vm_object_clear_flag() in > :vm_object_reference()? > > Well, yes... vm_object's are referenced for all sorts of things > temporarily. Everything from a process looking one up temporarily > to the swap code issuing I/O. None of these references have anything > to do with OBJ_ONEMAPPING. > I agree. Easy examples to appreciate are vm_map_clip_start and vm_map_clip_end. vm_map_clip_start takes a vm_map_entry and an address X as parameters. If X falls in the middle of the vm_map_entry, it splits the entry into two entries: one mapping everything up to X and one mapping everything after X. This can't possibly create two mappings to the same physical page, so clearing OBJ_ONEMAPPING isn't necessary but incrementing the underlying object's ref count is. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set.
:> I don't think this is an issue. The only double-mapped pages we care
:> about are those at the top-level (vm_object's connected directly to a
:> vm_map_entry). This is because these are the only pages effected by
:> write-faults and copy-on-write issues.
:>
:
:I disagree. If a backing object (BO) has OBJ_ONEMAPPING set, and someone
:call vm_map_delete(map, start, end) on an address space that references
:BO directly, then the system will crash and burn because vm_map_delete
:will (incorrectly) free physical pages:
:
: ...
:pmap_remove(map->pmap, s, e);
:if (object != NULL &&
:object->ref_count != 1 &&
:(object->flags & (OBJ_NOSPLIT|OBJ_ONEMAPPING)) == OBJ_ONEMAPPING &&
:(object->type == OBJT_DEFAULT || object->type == OBJT_SWAP)) {
:vm_object_collapse(object);
:vm_object_page_remove(object, offidxstart, offidxend, FALSE);
: ^
This is in the top-level object, so it isn't a problem. OBJ_ONEMAPPING
will be correct.
If there are problems anywhere, they are going to be in the collapse()
code.. Either vm_object_collapse() or vm_object_backing_scan()
(called by vm_object_qcollapse()).
I think vm_object_collapse() is safe, it will only remove pages from the
backing object if the reference count is 1, which guarentees that there
are no shared mappings no matter what the state OBJ_ONEMAPPING.
vm_object_backing_scan() also appears to be safe... it is either only
called from vm_object_collapse(), or vm_object_qcollapse().
vm_object_qcollapse() also only calls it if the backing object has
only one refrence count.
I think we're safe. I agree that not having OBJ_ONEMAPPING set properly
in underlying objects is bad design... but it's a design we inherited
and it's hard enough making the code work I don't want to introduce new
bugs fixing something that may not be broken (beyond not being documented
well).
:> and the other process cannot see that change. OBJ_ONEMAPPING is an
:> optimization that allows a process to dirty an anonymous (not vnode-backed)
:> page without doing a copy-on-write in the case where that process is
:> the ONLY process mapping the page.
:>
:
:Umm, it can do this without the OBJ_ONEMAPPING attribute, because
:the ref count on the object == 1. Note that the code from vm_object_shadow
:doesn't even check OBJ_ONEMAPPING:
:...
:I do care, because I don't want those pages freed by a vm_map_delete.
I think we're safe. If you can find a case where vm_map_delete()
screws us up, then we have a problem. I can't find a case.
:> be pre-pended or post-pended with the new pages rather then have to create
:> a new vm_object (and thus not be able to coalesce the associated
:> vm_map_entry structures) every time we take a copy-on-write fault.
:>
:
:Huh? It's always been the case that when a shadow object is created,
:its size is equal to the size of the mapping. This predates the
:existance of OBJ_ONEMAPPING. vm_map_lookup, where shadow objects
:are normally created on COW faults, has always done:
Ach, yes you're right. There's a case I fixed a while back... ah, I
remember what it was, it was the stack-extension code. That's what
I was thinking of. It has nothing to do with what we are talking
about now. Sorry, my mistake!
I think there are cases where the maps get broken up, though... where
is it.. Ah, here it is. The vm_map_split() code. I think this may
play a role when you have long fork() chains, but I haven't checked
for sure.
:> In this respect, the OBJ_ONEMAPPING optimization is *CRITICAL* to the
:> scaleability of our VM system.
:>
:
:It's not critical. COW worked just fine (performance-wise)
:before OBJ_ONEMAPPING. John Dyson introduced OBJ_ONEMAPPING
:so that he could free individual pages within an object earlier,
:without waiting for the entire object to be freed.
:
:Alan
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
