Re: jumbograms ( em) nfs a no go
On Sat, 1 Nov 2003, Terry Lambert wrote: I think at this point, you are going to have to look at the sources; IMO, it's a problem in some code that calls the ether_output() function directly with too large a packet, and since NFS doesn't manually implement TCP, that's not it. Hmmm. Is this maybe UDP? If so, the easiest fix is don't use UDP; FreeBSD's UDP fragment reassembly code sucks anyway, and gives an excellent means of implementing a DOS attack on the target system's available mbufs. If it's UDP, and you insist on it working, you might want to make sure that the packet goes through the UDP fragmentation and NFS rsize/wsize limitation code. I noticed in src/sys/dev/em/README that there are problems with jumbograms and UDP so I use TCP. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Thu, 30 Oct 2003, Doug Ambrisko wrote: Michal Mertl writes: | On Thu, 30 Oct 2003, Sam Leffler wrote: | | On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: | I wanted to test gigabit network performance and found out that current | (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU | set to 6000), Intel adapters and nfs (both UDP and TCP). | | I checked that the same thing works with 4.9. | | I then left one computer at 4.9 and upgraded the other to 5.0. When I | mount a partition from 5.0 machine I found out, that copying reliably | works only from 5.0 to 4.9. The other way around I see messages 'em0: | discard oversize frame (ether type 800 flags 3 len 67582 max 6014)' on | 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server | 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can | be revived by changing mtu back to 1500 and down/up sequence. | | I've ran many jumbogram tests of machines connected with a cross-over cable | and em devices at each end. If you've got a swtch in the middle make sure it | does the right thing. | | I also used exclusively crossover cable. The same configuration worked | with 4.9. The problem appears only with NFS. You might want to try this patch: Index: if_em.c === RCS file: /cvs/src/sys/dev/em/if_em.c,v retrieving revision 1.32 diff -c -r1.32 if_em.c *** if_em.c 15 Oct 2003 05:34:41 - 1.32 --- if_em.c 30 Oct 2003 19:39:49 - *** *** 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !1, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ --- 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !2, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ There was a few bugs in the system before in that there was insufficient error check in the bus_dma stuff. The issue was that HW was writing more then was the allocated due to (nsegments=1). This isn't the right fix but might help point to the issue. I don't have access to the HW to test it out anymore. Doug A. I'm afraid it doesn't help. The problem doesn't occur with FTP. For the last tests I've got two -current machines from Oct 30th. One exports a filesystem (server) and the other mounts it R/W (client). Copying /usr/src from server to client stalls (with 'em0: discard oversized frame...' on the receiver) and from client to server stalls too. NFS doesn't work (cp is uninterruptible and other access to remote fs stalls too). Client shows after some time 'nfs server 10.0.0.1:/usr: not responding'. At the time NFS doesn't work I can ping the other machine, so the interface isn't completely stuck. Copying one large file works from server to client but not the other way around. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Thu, 30 Oct 2003, Barney Wolff wrote: On Thu, Oct 30, 2003 at 08:04:58AM -0800, Sam Leffler wrote: I've ran many jumbogram tests of machines connected with a cross-over cable and em devices at each end. If you've got a swtch in the middle make sure it does the right thing. Just a minor note: GigE should not require a crossover cable. It's supposed to work to connect two GigE adapters with a straight-thru cable. I verified this with two Intel em NICs, quite a while ago. As I recall, when I used a crossover cable, I could not get the adapters to go to 1000, only 100. That might have been the cable, or not. I can confirm it works equally well with crossover as with straight cable. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
jumbograms ( em) nfs a no go
I wanted to test gigabit network performance and found out that current (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU set to 6000), Intel adapters and nfs (both UDP and TCP). I checked that the same thing works with 4.9. I then left one computer at 4.9 and upgraded the other to 5.0. When I mount a partition from 5.0 machine I found out, that copying reliably works only from 5.0 to 4.9. The other way around I see messages 'em0: discard oversize frame (ether type 800 flags 3 len 67582 max 6014)' on 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can be revived by changing mtu back to 1500 and down/up sequence. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Thu, 30 Oct 2003, Sam Leffler wrote: On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: I wanted to test gigabit network performance and found out that current (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU set to 6000), Intel adapters and nfs (both UDP and TCP). I checked that the same thing works with 4.9. I then left one computer at 4.9 and upgraded the other to 5.0. When I mount a partition from 5.0 machine I found out, that copying reliably works only from 5.0 to 4.9. The other way around I see messages 'em0: discard oversize frame (ether type 800 flags 3 len 67582 max 6014)' on 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can be revived by changing mtu back to 1500 and down/up sequence. I've ran many jumbogram tests of machines connected with a cross-over cable and em devices at each end. If you've got a swtch in the middle make sure it does the right thing. I also used exclusively crossover cable. The same configuration worked with 4.9. The problem appears only with NFS. I can repeat the whole test once again to make sure I didn't overlooked anything. It will take some time because I had to put one of the servers into production. -- Michal Mertl ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bktr(4) bufs plus patch
On Wed, 3 Sep 2003, Jens Rehsack wrote:
Michal Mertl wrote:
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't defined where it looks for
it. I added it there and the compilation and detection goes fine. I don't
know how to actually test it though.
[...]
Will anyone responsible take notice of this patch and commit it?
*** dev/bktr/bktr_reg.h.ori Sun Dec 8 10:40:14 2002
--- dev/bktr/bktr_reg.h Sun Dec 8 10:40:38 2002
***
*** 448,453
--- 448,454
struct bktr_i2c_softc {
int bus_owned;
+ device_t iicbus;
device_t iicbb;
device_t smbus;
};
*** dev/bktr/bktr_os.c.ori Sun Dec 8 10:39:13 2002
--- dev/bktr/bktr_os.c Sun Dec 8 10:39:35 2002
***
*** 499,513
destroy_dev(bktr-tunerdev);
destroy_dev(bktr-bktrdev);
- /* If this is unit 0, then destroy the alias entries too */
- #if (__FreeBSD_version =50)
- if (unit == 0) {
- destroy_dev(bktr-vbidev_alias);
- destroy_dev(bktr-tunerdev_alias);
- destroy_dev(bktr-bktrdev_alias);
- }
- #endif
-
/*
* Deallocate resources.
*/
--- 499,504
The destroy_dev calls for aliases have been removed in -current on 9th Dec
2002 (one day after I sent the email). See PR kern/36413. The fix hasn't
been MFCed but there's no need - the code is wrapped in '#if
(__FreeBSD_version = 50)'. The fix for BKTR_USE_FREEBSD_SMBUS hasn't
been commited.
I didn't send-pr but will recheck the status of things over the weekend
and perhaps will do.
To other readers: in my original email
(http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2276+0+archive/2002/freebsd-current/20021215.freebsd-current)
I talked about another problem (limits on the maximum number of devices).
When I reread what I wrote at the time I have to say 'sorry for my
English' :-).
--
Michal Mertl
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Twin CPU machine running with only one cpu?
On Mon, 9 Jun 2003, Brendon and Wendy wrote: Dear All, Just installed 5.1 RC1 on my Dual Prestonia Xeon box. Works great. In fact this is the first time i've had much success with the 5.x branch. Anyway, heres my question. Despite the fact that I've recompiled my kernel with SMP and IOAPIC enabled, I seem to have only one CPU running. At boot time the kernel reports starting CPU#1 at the end of boot time. The machdep.* systctls claim that I have two cpus, but no matter what I do I cannot get the CPU load over 48% (for instance running two c programs that loop infinitely with no delay)! Do you mean with the subject line that you have only one physical processor installed but you expect to see two in action because of HTT? If that's the case, your behaviour is normal because HTT is by default disabled. You should be able to see an idle kthread with 'top -S' eating 100% of CPU 1. You can toggle HTT on/off at any time with 'sysctl machdep.hlt_logical_cpus=0|1'. I think that when hlt_logical_cpus == 1 system shouldn't account for logical CPUs' idle time because it's confusing to see cpu load always = 50%. -- Michal Mertl [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: potential for foot-shooting with KLD's
How about `unset XX_load' ? It works only for acpi. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
potential for foot-shooting with KLD's
Imagine you decided to go with modular kernel. You comment out 'device random' in your kernel-config and place 'random_load=YES' in /boot/loader.conf. When you reboot and don't rebuild the kernel first, you have your machine unbootable - at least in case you previously had acpi in your kernel and acpi doesn't work without OS supplied dsdt (as in my case) or you need acpi as a module or any other module. The way out is to boot from install CDROM, have fixit floppy, mount the old root and remove the random.ko module. Which is pretty inconvenient, when you don't have the medias handy. The problem is that I can't ask loader not to load some module. It doesn't understand 'unset XX_load'. It doesn't work to say 'set XX_load=NO' either. The only way I found to make it not load the modules is to 'load /boot/kernel/kernel;set module_path=;boot'. Unfortunately it doesn't help me either because I need to load special acpi_dsdt.aml which isn't then loaded either. The fix could be to be able to say 'unset XX_load' or make 'set XX_load=NO' work. The other fix (probably more difficult to do) would be to make all modules loading/linking fail when they're statically compiled in. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
bktr(4) bufs plus patch
I found 2 bugs and some potential problems in bktr(4) code.
Bug 1:
Compilation with options BKTR_USE_FREEBSD_SMBUS failes. Error is
that code tries to use iicbus which isn't defined where it looks for
it. I added it there and the compilation and detection goes fine. I don't
know how to actually test it though.
Bug 2:
On module unload destroy_dev(9) is called on dev_alias which leads to
panic. According to MAKE_DEV(9) it's forbidden. The patch removes the code
to remove aliases. All seems to work fine.
Problem 1:
When using bktr(4) in a module, there's a helper module
bktr_mem, which allocates memory for bktr(4) devices. There is fixed limit
(#define BKTR_MEM_MAX_DEVICES 8 in bktr_mem.h) on number of devices
supported - it should at least be mentioned somewhere and possibly raised
- I have 16 devices and soon will be using more.
Problem 2:
There's another limit on number of bktr(4) devices in device creation
on lines 443-448 in bktr_os.c.
bktr-bktrdev = make_dev(bktr_cdevsw, unit,
0, 0, 0444, bktr%d, unit);
bktr-tunerdev= make_dev(bktr_cdevsw, unit+16,
0, 0, 0444, tuner%d, unit);
bktr-vbidev = make_dev(bktr_cdevsw, unit+32,
0, 0, 0444, vbi%d , unit);
If I read the code right it seems to limit the maximum number of devices
to 16. I don't see why it can't be much more here - say 256 (so change +16
to +256 and +32 to +512. In DEVFS world users should care about
majors/minors but with normal /dev it could be problem.
Problem 3: (affacting mainly STABLE)
In MAKEDEV there's only one char allowed so one can create only 10
devices. Patch could look like this:
*** MAKEDEV.ori Sun Dec 8 11:02:38 2002
--- MAKEDEV Sun Dec 8 11:07:01 2002
***
*** 1552,1559
chmod 444 meteor$unit
;;
! bktr?)
unit=`expr $i : 'bktr\(.*\)'`
mknod bktr$unit c 92 `unit2minor $unit`
mknod tuner$unit c 92 `unit2minor $((16 + $unit))`
mknod vbi$unit c 92 `unit2minor $((32 + $unit))`
--- 1552,1562
chmod 444 meteor$unit
;;
! bktr*)
unit=`expr $i : 'bktr\(.*\)'`
+ if [ ${unit} -lt 0 -o ${unit} -gt 15 ]; then
+ die 3 bktr(4) unit limited to 0-15
+ fi
mknod bktr$unit c 92 `unit2minor $unit`
mknod tuner$unit c 92 `unit2minor $((16 + $unit))`
mknod vbi$unit c 92 `unit2minor $((32 + $unit))`
--
Michal Mertl
[EMAIL PROTECTED]
*** dev/bktr/bktr_reg.h.ori Sun Dec 8 10:40:14 2002
--- dev/bktr/bktr_reg.h Sun Dec 8 10:40:38 2002
***
*** 448,453
--- 448,454
struct bktr_i2c_softc {
int bus_owned;
+ device_t iicbus;
device_t iicbb;
device_t smbus;
};
*** dev/bktr/bktr_os.c.ori Sun Dec 8 10:39:13 2002
--- dev/bktr/bktr_os.c Sun Dec 8 10:39:35 2002
***
*** 499,513
destroy_dev(bktr-tunerdev);
destroy_dev(bktr-bktrdev);
- /* If this is unit 0, then destroy the alias entries too */
- #if (__FreeBSD_version =50)
- if (unit == 0) {
- destroy_dev(bktr-vbidev_alias);
- destroy_dev(bktr-tunerdev_alias);
- destroy_dev(bktr-bktrdev_alias);
- }
- #endif
-
/*
* Deallocate resources.
*/
--- 499,504
Re: ACPI + Compaq Armada m700
Hello, Last night I cvsupped from 4.6-STABLE to 5.0-CURRENT. I do know the risks of using -CURRENT. Unfortunately I am having a problem with ACPI on boot. I have to issue the following to get the machine to boot boot unset acpi_load boot set boot_verbose=YES boot boot -v then the usual fsck and mount commands. I have read the acpi manpage along with acpiconfig. Unfortunately this didn't shed much light on fixing this problem on a permanent basis. I too have Armada m700 and am seeing the problem. The right solution is to have HP/Compaq fix the BIOS (which isn't likely) or to get someone who has a clue about ACPI look at our acpidump and find what's wrong there and fix the BIOS locally (ACPI configuration can be fetched from disk instead of from BIOS). The reason our computers don't boot is that under newer -current with ACPI it's either full HW configuration via ACPI and m700's ACPI does define our PCI bus (or something) wrong way (or there's a bug in ACPI code in -current). Meanwhile (forever I suppose) you could disable ACPI permanently by adding hint.acpi.0.disabled=1 to /boot/loader.conf[.local]. I also have hint.atkbd.0.flags=0x3 in there which helps with using my m700 with the docking station BTW. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
system locks with vnode backed md(4)
0 0 204 new [IWAIT] irq11: bktr0 bktr7* 20 c120e938 d66440000 0 0 204 new [IWAIT] irq13: 19 c120eb10 d66450000 0 0 204 new [IWAIT] swi5: acpitaskq 18 c120ece8 d66460000 0 0 204 new [IWAIT] swi3: cambio 17 c3cc d78180000 0 0 204 new [IWAIT] swi2: camnet 16 c3cc01d8 d78190000 0 0 204 new [IWAIT] swi5: task queue 15 c3cc03b0 d781a0000 0 0 204 norm[SLPQ sleep c03b5040][SLP] random 4 c1207000 d65cb0000 0 0 204 norm[SLPQ g_down c03934b0][SLP] g_down 3 c12071d8 d66380000 0 0 204 norm[SLPQg_up c03934ac][SLP] g_up 2 c12073b0 d66390000 0 0 204 norm[SLPQ g_events c03934a4][SLP] g_event 14 c1207588 d663a0000 0 0 204 new [IWAIT] swi4: vm 13 c1207760 d663b0000 0 0 20c norm[RUNQ] swi6: tty:sio clock 12 c1207938 d663c0000 0 0 204 norm[IWAIT] swi1: net 11 c1207b10 d663d0000 0 0 20c norm[Can run] idle 1 c1207ce8 d663e0000 0 1 0004200 norm[SLPQwait c1207ce8][SLP] init 10 c120e000 d663f0000 0 0 204 norm[CVQ ktrace c03c50c4][SLP] ktrace 0 c0394720 c04ff0000 0 0 200 norm[SLPQ sched c0394720][SLP] swapper -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
unkillable process - 'mdconfig -t vnode' on small file
Subject says it all.
I wanted to make vnode-backed md(4) and forgot to specify size, thas it
after 'touch mdfile;mdconfig -a -t vnode -f mdfile' mdconfig process can't
be killed. It's wchan ('ps axO wchan|grep mdconf') is mddest.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: system locks with vnode backed md(4)
On Sat, 30 Nov 2002, Michal Mertl wrote: Including rwatson because of the thread on hackers@. Sorry for follow-up to myself. Recently there was a discussion about jails on some freebsd list. Someone recommended vnconfig(8)ed file-backed disk for jail file systems. Terry wrote there are problems with it. I liked the idea and played with mdconfig(8)ed devices on current. Terry was right - I can easily make the system deadlock. I really like the idea of jails in vnode-backed I'm now unable to make it dead-lock again. Yet it happened quite easily. I had more md backing files in the same directory at the beginning (to test Terry's suspicion mentioned in thread 'jail' on hackers@). After the first lock-up I tried 'while(1);tar xzf ports.tgz; rm -rf ports;end' on normal filesystem, let it run for long time ( 1h) and then I found the system almost dead-locked too (the system worked, but anything accessing disk was painfully slow - it might be the same problem or it might be different. It never ended (at least for ~30 mins when I didn't (weren't able) anything on it). syncer and bufdaemon and others were in wdrain. Disk as seen in systat -v showed maximal usage yet no inodes were resolved. Sometimes during that test I had lock order reversal: ../../../kern/kern_synch.c:152: sleeping with mntvnode locked from ../../../kern/vfs_subr.c:3016 lock order reversal 1st 0xc03a0aa0 mntvnode (mntvnode) @ ../../../kern/vfs_subr.c:3016 The 2nd isn't unfortunately saved in logs but it was Giant. I'll try to get more problems and get more info (show lockedvnods, show locks). show locks with first dead-lock showed only Giant AFAIR. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: system locks with vnode backed md(4)
Ok, I got another one. DDB output attached. I did all kinds of operations to trigger it - had 3 md mounted from the same dir, in 2 of them doing my ports.tgz torture test and in root file system I had 'find . -inum 1231231' running. One find finished succesfully but then it finally locked-up. Yeah, vnode locks and other lockmgr locks don't show up in 'show locks', since only SMPng locking primitives are tracked by WITNESS. I see. There are a fair number of vnode locking deadlock scenarios that are unavoidable where we rely on grabbing vnode locks out of the directory structure lock order. This occurs for vnode-backed md devices, quotas, and UFS1 extended attributes, and probably some other situations. I suspect that Terry is correct that operations on the vnode backing file storage directory are triggering the problem, since that increases the chances that a vnode lock race to root will occur from both the file system backed into the md device, and for the md backing vnodes during blocking I/O. If you can avoid directory operations on the md backing directory, that would probably be one way to avoid triggering the bug. I'm afraid this doesn't sound too good for me. Seeing it reproduced would probably confirm that this is the case. On the other hand, there may be other deadlocks in the vnode/ufs/md code that can be more easily corrected than this general VFS problem, so details there would be very useful. May be the attached one will allow someone to track something down. PS: Sorry if you have problems with attachment, I myself find them difficult to read (I'm receivind digest of this list - isn't there a possibility to have it in mime form (like Buqtraq and others)? -- Michal Mertl [EMAIL PROTECTED] db show lockedvnods Locked vnodes 0xc3ef8b90: tag ufs, type VDIR, usecount 1, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1993 ino 6593, on dev ad0s1a (4, 4) 0xc3efea68: tag ufs, type VREG, usecount 2, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 599 ino 6596, on dev ad0s1a (4, 4) 0xc4ac7818: tag devfs, type VCHR, usecount 1297, writecount 0, refcount 30, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by pid 8 0xc574f250: tag ufs, type VREG, usecount 2, writecount 1, refcount 8, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1919 ino 7, on dev ad0s2e (4, 10) 0xc3f3c940: tag ufs, type VREG, usecount 2, writecount 1, refcount 225, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 439 ino 3, on dev ad0s2e (4, 10) 0xc559d940: tag ufs, type VREG, usecount 0, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1965 ino 4, on dev ad0s2e (4, 10) 0xc5c84cb8: tag ufs, type VREG, usecount 2, writecount 1, refcount 426, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 810 ino 5, on dev ad0s2e (4, 10) 0xc4a5a000: tag ufs, type VDIR, usecount 0, writecount 0, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1990 ino 96988, on dev md0 (4, 12) 0xc444f128: tag ufs, type VDIR, usecount 1, writecount 0, refcount 2, lock type ufs: EXCL (count 1) by pid 1964 ino 14330, on dev md0 (4, 12) 0xc4454818: tag ufs, type VNON, usecount 1, writecount 0, refcount 0, lock type ufs: EXCL (count 1) by pid 1964 ino 14336, on dev md0 (4, 12) 0xc5183de0: tag ufs, type VDIR, usecount 0, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by pid 1992 ino 5090, on dev md1 (4, 14) db show locks exclusive sleep mutex Giant r = 0 (0xc0399660) locked @ ../../../kern/kern_intr.c:534 db ps pid proc addruid ppid pgrp flag stat wmesgwchan cmd 1993 c4819938 e17970000 1737 1993 0004002 norm[SLPQ newbuf c03ede10][SLP] find 1992 c481b3b0 e179c0000 547 1992 0004002 norm[SLPQ getblk ce3eabb8][SLP] rm 1990 c4819b10 e17980000 1962 1990 0004002 norm[SLPQ getblk ce2d1ba4][SLP] cp 1965 c4819000 e174e0000 1964 1964 0006002 norm[SLPQ newbuf c03ede10][SLP] gzip 1964 c481b938 e179f0000 436 1964 0004002 norm[SLPQ biord ce2f743c][SLP] tar 1962 c4b57000 e17c30000 1958 1962 2004002 norm[SLPQ pause e17c3000][SLP] csh 1958 c4b571d8 e17c4000 1001 1779 1958 0004102 norm[SLPQwait c4b571d8][SLP] su 1919 c48193b0 e175e0000 0 0 204 norm[SLPQ newbuf c03ede10][SLP] md2 1779 c4819588 e175f000 1001 1778 1779 2004002 norm[SLPQ pause e175f000][SLP] tcsh 1778 c4b59000 e17cb000 1001 1775 360 100 norm[CVQ select c039cbe4][SLP] sshd 1775 c4b59588 e18040000 360 360 100 norm[SLPQ sbwait c3f00e64][SLP] sshd 1737 c4b591d8 e17cc0000 1736 1737 2004002 norm[SLPQ pause e17cc000][SLP] csh 1736 c48191d8 e174f000 1001 458 1736 0004102 norm[SLPQwait c48191d8][SLP] su 810 c4b57ce8 e17ca0000 0 0 204 norm[SLPQ
WITNESS complaints
I keep getting lots of /usr/src/sys/kern/kern_sysctl.c:1002: could sleep with drm memory locked from @/dev/drm/drm_memory.h:217 and /usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0 locked from /usr/src/sys/dev/sound/pcm/sound.c:134 /usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:fake locked from /usr/src/sys/dev/sound/pcm/channel.c:677 /usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:play:0 locked from /usr/src/sys/dev/sound/pcm/channel.c:677 /usr/src/sys/vm/uma_core.c:1330: could sleep with pcm0:record:0 locked from /usr/src/sys/dev/sound/pcm/channel.c:677 for long time. I don't know, how serious these are and how much work is required to fix it. Otherwise it's proabably just a slight nuisance hidden for most users (once GENERIC is without WITNESS). I use both as modules but I'm pretty sure I had the same problem with both compiled into the kernel. In case it matters sound device is detected as: pcm0: VIA VT82C686A port 0xe400-0xe403,0xe000-0xe003,0xdc00-0xdcff irq 12 at device 7.5 on pci0 pcm0: ac97 codec id 0x49434511 (ICEnsemble ICE1232) pcm0: ac97 codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, Reserved 27 pcm0: ac97 primary codec extended features variable rate PCM, AMAP and video is drm0: 3dfx Voodoo3 3000 port 0xc000-0xc0ff mem 0xd800-0xd9ff,0xd400-0xd5ff irq 10 at device 0.0 on pci1 info: [drm] Initialized tdfx 1.0.0 20010216 on minor 0 The complaints about drm memory are shown in groups of about 25 same messages on each invocation of 'sysctl hw.dri' (or -a) but otherwise they seem to be quiet. The complaints about pcm happen only on boot (about 30). I'm ready to send more detail if required but I suppose it's going to be general problem - I've seen it mentioned (at least the pcm one) several times. Thanks. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: crash with network load (in tcp syncache ?)
On Fri, 1 Nov 2002, Bill Fenner wrote:
sonewconn() hands sofree() a self-inconsistent socket -- so-so_head is
set, so so must be on a queue, but sonewconn() hasn't put it on a queue yet.
Please try this patch.
Bill
Index: uipc_socket2.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.104
diff -u -r1.104 uipc_socket2.c
--- uipc_socket2.c18 Sep 2002 19:44:11 - 1.104
+++ uipc_socket2.c1 Nov 2002 22:40:52 -
@@ -192,7 +192,7 @@
return ((struct socket *)0);
if ((head-so_options SO_ACCEPTFILTER) != 0)
connstatus = 0;
- so-so_head = head;
+ so-so_head = NULL;
so-so_type = head-so_type;
so-so_options = head-so_options ~ SO_ACCEPTCONN;
so-so_linger = head-so_linger;
@@ -209,6 +209,7 @@
return ((struct socket *)0);
}
+ so-so_head = head;
if (connstatus) {
TAILQ_INSERT_TAIL(head-so_comp, so, so_list);
so-so_state |= SS_COMP;
This patch fixes the panics for me. Thanks a lot. I believe it should be
commited.
BTW: I get about 850 fetches pers second on UP an 600 SMP (the same
machine and settings). Don't know if it's expected in this usage pattern.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: crash with network load (in tcp syncache ?)
On Fri, 1 Nov 2002, Terry Lambert wrote: Bill Fenner wrote: I think this can still crash (just like my patch); the problem is in what happens when it fails to allocate memory. Unless you set one of the flags, it's still going to panic in the same place, I think, when you run out of memory. No. The flags are only checked when so_head is not NULL. sonewconn() was handing sofree() an inconsistent struct so (so_head was set without being on either queue), i.e. sonewconn() was creating an invalid data structure. You're right... I missed that; I was thinking too hard on the other situations (e.g. soabort()) that could trigger that code, and no enough on the code itself. The call in sonewconn() used to be to sodealloc(), which didn't care about whether or not the data structure was self-consistent. The code was refactored to do reference counting, but the fact that the socket was inconsistent at that point wasn't noticed until now. Yeah; I looked at doing a ref() of the thing as a partial fix, but the unref() did the sotryfree() anyway. The problem is not at all based on what happens in the allocation or protocol attach failure cases. The SYN cache is not involved, this is a bug in sonewconn(), plain and simple. I still think there is a potential failure case, but the amount of code you'd have to read through to follow it is immense. It has to do with the conection completing at NETISR, instead of in a process context, in the allocation failure case. I ran into the same issue when trying to run connections to completion up to the accept() at interrupt, in the LRP case. The SYN cache case is very similar, in the case of a cookie that hits when there are no resources remaining. He might be able to trigger it with his setup, by setting the cache size way, way don, and thus relying on cookies, and then flooding it with conection requests until he runs it out of resources. Do I read you correctly that Bill's patch is probably better than yours (I tested both, both fix the problem)? If you still believe there's a problem (bug) I may trigger with some setting please tell me. I don't know how to make syncookies kick in - I set net.inet.tcp.cachelimit to 100 but it doesn't seem to make a difference but I don't know what am I doing :-). I imagine syncache doesn't grow much when I'm connecting from signle IP and connections are quickly eastablished. I'll be able to do some tests on monday - this is a computer at work. FWIW netstat -m during the benchmark run shows (I read it that it doesn't have problem - even just before the crash): mbuf usage: GEN list: 0/0 (in use/in pool) CPU #0 list:71/160 (in use/in pool) CPU #1 list:79/160 (in use/in pool) Total: 150/320 (in use/in pool) Maximum number allowed on each CPU list: 512 Maximum possible: 34560 Allocated mbuf types: 80 mbufs allocated to data 70 mbufs allocated to packet headers 0% of mbuf map consumed mbuf cluster usage: GEN list: 0/0 (in use/in pool) CPU #0 list:38/114 (in use/in pool) CPU #1 list:41/104 (in use/in pool) Total: 79/218 (in use/in pool) Maximum number allowed on each CPU list: 128 Maximum possible: 17280 1% of cluster map consumed 516 KBytes of wired memory reserved (37% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
crash with network load (in tcp syncache ?)
) at sofree+0x6e
sonewconn(c43874d8,2,c01cc210,c46bb880,c1672d00) at sonewconn+0xf8
syncache_socket(c46bb6e8,c43874d8,c1662200,c42543e0,c1f6c820) at syncache_socket+0x1f
syncache_expand(d6a62b3c,c1f6c834,d6a62b10,c1662200,5000) at syncache_expand+0x98
tcp_input(c1662200,14,c1630018,d6a60010,d6a60010) at tcp_input+0x6a8
ip_input(c1662200,c031ac00,d6a62ccc,c01b293a,c031aba0) at ip_input+0x793
ipintr(c1639d02,c162d980,c162d980,c162b400,d6a62d08) at ipintr+0xd4
swi_net(0,0,0,0,c1638540) at swi_net+0x23
ithread_loop(c162b400,d6a62d48,0,0,0) at ithread_loop+0x1d4
fork_exit(c01a8bf0,c162b400,d6a62d48) at fork_exit+0x94
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd6a62d7c, ebp = 0 ---
gdb trace
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc01bd1ca in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:364
#2 0xc01bd487 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc013e5e2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc013e562 in db_command (last_cmdp=0xc0310460, cmd_table=0x0,
aux_cmd_tablep=0xc030996c, aux_cmd_tablep_end=0xc0309970)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc013e676 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc014132a in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_trap.c:72
#7 0xc02b02e0 in kdb_trap (type=3, code=0, regs=0xd6a629b0)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc02c939a in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = -980418544, tf_edi = -1050436352,
tf_esi = 256, tf_ebp = -693753348, tf_isp = -693753380, tf_ebx = 0, tf_edx
= 0, tf_ecx = 1021, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip =
-1070922283, tf_cs = 8, tf_eflags = 646, tf_esp = -1070583802, tf_ss =
-1070657532})
at /usr/src/sys/i386/i386/trap.c:605
#9 0xc02b1b18 in calltrap () at {standard input}:99
#10 0xc01bd46f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc01f7e1e in sofree (so=0xc58f05d0) at
/usr/src/sys/kern/uipc_socket.c:312
#12 0xc01fa508 in sonewconn (head=0xc43874d8, connstatus=2)
at /usr/src/sys/kern/uipc_socket2.c:208
#13 0xc023f42f in syncache_socket (sc=0x2, lso=0xc43874d8, m=0xc1662200)
at /usr/src/sys/netinet/tcp_syncache.c:564
#14 0xc023f748 in syncache_expand (inc=0xd6a62b3c, th=0xc1f6c834,
sop=0xd6a62b10, m=0xc1662200) at
/usr/src/sys/netinet/tcp_syncache.c:783
#15 0xc0239978 in tcp_input (m=0xc1f6c834, off0=20)
at /usr/src/sys/netinet/tcp_input.c:713
#16 0xc0235143 in ip_input (m=0xc1662200)
at /usr/src/sys/netinet/ip_input.c:916
#17 0xc0235234 in ipintr () at /usr/src/sys/netinet/ip_input.c:934
#18 0xc02295f3 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:97
#19 0xc01a8dc4 in ithread_loop (arg=0xc162b400)
at /usr/src/sys/kern/kern_intr.c:535
#20 0xc01a7c54 in fork_exit (callout=0xc01a8bf0 ithread_loop, arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:860
Please keep me on cc: list, I'm getting digests so I would be slow in
reponsding.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
bug in sysv semaphores on -CURRENT
There seems to be bug in $SUBJ. When I run attached program on recent
-CURRENT, it always (after several seconds) triggers the bug. I first
suspected a problem in the program's logic but on stable in runs just
fine.
Esentially I use piece of shm memory to pass some data between several
processes. I implemented simple locking functions with semaphores and
noticed it behaves strange on -CURRENT and ok on -STABLE.
CCing Alfred because he made some changes into the kernel part of $SUBJ. I
don't expect the bug is new though.
May I ask someone with older -CURRENT to try running the program for a
minute?
--
Michal Mertl
[EMAIL PROTECTED]
#include sys/types.h
#include sys/ipc.h
#include sys/sem.h
#include sys/shm.h
#include errno.h
#include stdlib.h
#include stdio.h
#include string.h
#include unistd.h
#define MY_SHM_MAGIC 0x56d9f13b
typedef struct {
struct shmid_ds shm_ds;
struct semid_ds sem_ds;
pid_tsem_owner;
int sem_id;
int shm_id;
int size;
} s_ipc_cfg;
s_ipc_cfg *ipc_cfg = NULL;
int
ipc_setup(int size)
{
int skey;
int ipc_tok;
void *shm_addr;
struct shmid_ds shm_ds;
union semun sem_arg;
ipc_tok = IPC_PRIVATE;
if ((skey = shmget(ipc_tok, size, SHM_R | SHM_W
| IPC_CREAT)) == -1) {
fprintf(stderr, shmget()\n);
return (-1);
}
if ((shmctl(skey, IPC_STAT, shm_ds)) == -1) {
fprintf(stderr, shmctl()\n);
return (-1);
}
if ((shm_addr = shmat(skey, NULL, 0)) == (void *)-1) {
fprintf(stderr, shmat()\n);
return (-1);
}
ipc_cfg = shm_addr;
ipc_cfg-size = size - sizeof(s_ipc_cfg);
memcpy(ipc_cfg, shm_ds, sizeof(shm_ds));
ipc_cfg-shm_id = skey;
if (shmctl(ipc_cfg-shm_id, IPC_RMID, NULL) == -1) {
fprintf(stderr, shmctl() IPC_RMID\n);
return (-1);
}
if ((skey = semget(ipc_tok, 1, SEM_R | SEM_A | IPC_CREAT)) == -1) {
fprintf(stderr, semget()\n);
return (-1);
}
ipc_cfg-sem_id = skey;
sem_arg.buf = (void *)ipc_cfg-sem_ds;
if (semctl(ipc_cfg-sem_id, 0, IPC_STAT, sem_arg) == -1) {
fprintf(stderr, semctl()\n);
return (-1);
}
ipc_cfg-sem_owner = -1;
sem_arg.val = 1;
semctl(ipc_cfg-sem_id, 0, SETVAL, sem_arg);
return (0);
}
void
ipc_shutdown(void)
{
if (ipc_cfg)
semctl(ipc_cfg-sem_id, 0, IPC_RMID);
}
int
ipc_lock(int wait, int undo)
{
struct sembuf sem_buf;
int err;
sem_buf.sem_num = 0;
sem_buf.sem_op = -1;
sem_buf.sem_flg = wait ? 0 : IPC_NOWAIT;
sem_buf.sem_flg |= undo ? SEM_UNDO : 0;
err = semop(ipc_cfg-sem_id, sem_buf, 1);
if (err == -1) {
if (wait errno == EAGAIN)
return (-2);
fprintf(stderr, %d: semop()\n, getpid());
return (-1);
}
printf(%d: ipc_lock()\n, getpid());
ipc_cfg-sem_owner = getpid();
return (0);
}
int
ipc_unlock(void)
{
struct sembufsem_buf;
int err;
if (ipc_cfg-sem_owner != getpid()) {
fprintf(stderr, %d: can't unlock (bug), owner: %d\n,
getpid(), ipc_cfg-sem_owner);
return (-1);
}
if (semctl(ipc_cfg-sem_id, 0, GETVAL) != 0) {
fprintf(stderr, %d: can't unlock (bug), not locked\n,
getpid());
return (-1);
}
printf(%d: ipc_unlock()\n, getpid());
sem_buf.sem_num = 0;
sem_buf.sem_op = 1;
sem_buf.sem_flg = 0;
err = semop(ipc_cfg-sem_id, sem_buf, 1);
if (err == -1) {
fprintf(stderr, %d: semop()\n, getpid());
return (-1);
}
ipc_cfg-sem_owner = -1;
return (0);
}
int
ipc_locked(void)
{
return (semctl(ipc_cfg-sem_id, 0, GETVAL) ? 0 : 1);
}
int
ipc_owned(void)
{
return (ipc_locked()
ipc_cfg-sem_owner == getpid() ? 1 : 0);
}
int
ipc_useit(void)
{
if (!ipc_owned()) {
if (ipc_lock(1, 0) 0) {
printf(%d: _ipc_getpart() can't lock\n,
getpid());
return (-1);
}
}
if (ipc_unlock() 0) {
fprintf(stderr, %d: _ipc_getpart() can't unlock\n,
getpid());
return (-1);
}
return (0);
}
int
be_child
Re: bug in sysv semaphores on -CURRENT
On Fri, 6 Sep 2002, Alfred Perlstein wrote:
Alfred (thanks) found a bug in my code. Sorry for the fuss folks :-(.
* Michal Mertl [EMAIL PROTECTED] [020906 06:10] wrote:
There seems to be bug in $SUBJ. When I run attached program on recent
-CURRENT, it always (after several seconds) triggers the bug. I first
suspected a problem in the program's logic but on stable in runs just
fine.
Esentially I use piece of shm memory to pass some data between several
processes. I implemented simple locking functions with semaphores and
noticed it behaves strange on -CURRENT and ok on -STABLE.
CCing Alfred because he made some changes into the kernel part of $SUBJ. I
don't expect the bug is new though.
May I ask someone with older -CURRENT to try running the program for a
minute?
I found your bug.
In the function ipc_unlock() you do this:
int
ipc_unlock(void)
{
struct sembufsem_buf;
int err;
if (ipc_cfg-sem_owner != getpid()) {
fprintf(stderr, %d: can't unlock (bug), owner: %d\n,
getpid(), ipc_cfg-sem_owner);
return (-1);
}
if (semctl(ipc_cfg-sem_id, 0, GETVAL) != 0) {
fprintf(stderr, %d: can't unlock (bug), not locked\n,
getpid());
return (-1);
}
printf(%d: ipc_unlock()\n, getpid());
sem_buf.sem_num = 0;
sem_buf.sem_op = 1;
sem_buf.sem_flg = 0;
err = semop(ipc_cfg-sem_id, sem_buf, 1);
if (err == -1) {
fprintf(stderr, %d: semop()\n, getpid());
return (-1);
}
ipc_cfg-sem_owner = -1;
return (0);
}
Problem is that you're messing with lock state after dropping your
semaphore!
If you move the
ipc_cfg-sem_owner = -1;
to before the semop() call it seems to fix things.
-Alfred
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: VLock and 5.0 DP1
When i try to compile Vlock from ports, i get: cc -O -pipe -DUSE_PAM -c vlock.c cc -O -pipe -DUSE_PAM -c signals.c cc -O -pipe -DUSE_PAM -c help.c cc -O -pipe -DUSE_PAM -c terminal.c cc -O -pipe -DUSE_PAM -c input.c input.c:64: security/pam_misc.h: No such file or directory input.c:67: `misc_conv' undeclared here (not in a function) input.c:67: initializer element is not constant input.c:67: (near initialization for `PAM_conversation.conv') vlock's PAM handling is written for LinuxPAM. There's some icompatibility issue with OpenPAM which I didn't look much into but it helps to remove USE_PAM. You don't have to tell the vlock you're using shadow passwords because FreeBSD's getpwent(3) returns password to the program run by root automatically. To run the program as root you must make sure it's owned by root and has suid bit set (or always run it as root). This easily may be security hole if there's bug in the program. HTH -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panics with CardBus
0xc016603c in pci_print_verbose (dinfo=0xc18c2900) at
/usr/src/sys/dev/pci/pcivar.h:211
#13 0xc014d2e1 in cardbus_attach_card (cbdev=0xc1839980) at
/usr/src/sys/dev/cardbus/cardbus.c:192
#14 0xc0162b42 in pccbb_insert (sc=0xc0b4fa00) at card_if.h:67
#15 0xc0162959 in pccbb_event_thread (arg=0xc0b4fa00) at
/usr/src/sys/dev/pccbb/pccbb.c:867
#16 0xc01b97aa in fork_exit (callout=0xc01628fc pccbb_event_thread,
arg=0xc0b4fa00, frame=0xc8d99d48)
at /usr/src/sys/kern/kern_fork.c:799
(kgdb) up 12
#12 0xc016603c in pci_print_verbose (dinfo=0xc18c2900) at
/usr/src/sys/dev/pci/pcivar.h:211
211 return PCI_READ_CONFIG(device_get_parent(dev), dev, reg,
width);
(kgdb) print *dinfo
$2 = {pci_links = {stqe_next = 0x0}, resources = {slh_first = 0x0}, cfg =
{dev = 0x0, subvendor = 4445, subdevice = 4481,
vendor = 4445, device = 3, cmdreg = 0, statreg = 528, baseclass = 2
'\002', subclass = 0 '\000', progif = 0 '\000',
revid = 3 '\003', hdrtype = 0 '\000', cachelnsz = 8 '\b', intpin = 1
'\001', intline = 128 '\200', mingnt = 20 '\024',
maxlat = 40 '(', lattimer = 168 '', mfdev = 1 '\001', nummaps = 6
'\006', bus = 2 '\002', slot = 0 '\000',
func = 0 '\000', pp_cap = 65041, pp_status = 224 '', pp_pmcsr = 226
'', pp_data = 0 '\000'}, conf = {pc_sel = {
pc_bus = 2 '\002', pc_dev = 0 '\000', pc_func = 0 '\000'}, pc_hdr =
0 '\000', pc_subvendor = 4445,
pc_subdevice = 4481, pc_vendor = 4445, pc_device = 3, pc_class = 2
'\002', pc_subclass = 0 '\000',
pc_progif = 0 '\000', pc_revid = 3 '\003', pd_name = '\000' repeats
16 times, pd_unit = 0}}
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
latest pccard/cardbus megacommit broke on-boot detection
I have Xircom CBEM-56G (on card printed RBEM-56G-100) which used to be detected on boot without problem on -CURRENT. After todays cvsup and buildworld the card is no longer detected. It works when I unplug it and put it back. Is it expected behaviour? It seems to me it can be and the commit is work in progress to make it behave more like OLDCARD ? -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs and sendfile problem (corrupted data)
On Sun, 30 Dec 2001, Terry Lambert wrote:
Michal Mertl wrote:
I wrote about the issue once before but now I know more about the
problem.
I have ntfs partition mounted ro on current. I can read from it without
problems. But I noticed I get corrupted data (the corrupted file has
right size but contains mostly zeros) when using ftpd to read them.
I'm pretty sure the problem is thus in sendfile(2) and/or ntfs fs support.
The getpages() doesn't work like you think in NTFS.
Thanks for the info, but I wasn't thinking much about how it works. I just
found there's something wrong. Matt suggested a fix to smbfs which I
tweaked a bit to fit into ntfs_vnops.c source but it panics.
my patch (-currentntfs modified Matt's smbfs_vnops.c patch):
--- ntfs_vnops.c.oriMon Dec 31 11:16:04 2001
+++ ntfs_vnops.cMon Dec 31 11:04:02 2001
@@ -85,6 +85,8 @@
static int ntfs_fsync __P((struct vop_fsync_args *ap));
static int ntfs_pathconf __P((void *));
+static int ntfs_createvobject __P((struct vop_createvobject_args *ap));
+
intntfs_prtactive = 1; /* 1 = print out reclaim of active vnodes */
static int
@@ -741,6 +743,7 @@
{ vop_access_desc, (vop_t *)ntfs_access },
{ vop_close_desc, (vop_t *)ntfs_close },
+ { vop_createvobject_desc, (vop_t *)ntfs_createvobject },
{ vop_open_desc, (vop_t *)ntfs_open },
{ vop_readdir_desc, (vop_t *)ntfs_readdir },
{ vop_fsync_desc, (vop_t *)ntfs_fsync },
@@ -751,6 +754,17 @@
{ NULL, NULL }
};
+
+static int
+ntfs_createvobject(ap)
+ struct vop_createvobject_args /* {
+ struct vnode *vp;
+ struct ucred *cred;
+ struct thread *td;
+ } */ *ap;
+{
+ return(0);
+}
static
struct vnodeopv_desc ntfs_vnodeop_opv_desc =
-
This is backtrace :
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492
#1 0xc01c0800 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:335
#2 0xc01c0c4f in panic (fmt=0xc02a9f2a from debugger)
at /usr/src/sys/kern/kern_shutdown.c:634
#3 0xc0135af5 in db_panic (addr=-1071094807, have_addr=0, count=-1,
modif=0xcace1a6c ) at /usr/src/sys/ddb/db_command.c:452
#4 0xc0135a95 in db_command (last_cmdp=0xc02f1b18, cmd_table=0xc02f1938,
aux_cmd_tablep=0xc02e9b58, aux_cmd_tablep_end=0xc02e9b5c)
at /usr/src/sys/ddb/db_command.c:348
#5 0xc0135b5f in db_command_loop () at /usr/src/sys/ddb/db_command.c:474
#6 0xc0137f83 in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_trap.c:72
#7 0xc0286178 in kdb_trap (type=3, code=0, regs=0xcace1b6c)
at /usr/src/sys/i386/i386/db_interface.c:167
#8 0xc0292568 in trap (frame={tf_fs = 24, tf_es = -1070399472, tf_ds =
16,
tf_edi = -89802, tf_esi = 256, tf_ebp = -892462152,
tf_isp = -892462184, tf_ebx = 514, tf_edx = -1070719377, tf_ecx =
32,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071094807, tf_cs
= 8,
tf_eflags = 70, tf_esp = -1070719393, tf_ss = -1070857413})
at /usr/src/sys/i386/i386/trap.c:585
#9 0xc02863e9 in Debugger (msg=0xc02c033b panic) at
machine/cpufunc.h:66
#10 0xc01c0c38 in panic (
fmt=0xc02c8820 open: vmio vnode has no backing object after vn_open)
at /usr/src/sys/kern/kern_shutdown.c:621
#11 0xc01fe31c in open (td=0xca793c04, uap=0xcace1d20)
at /usr/src/sys/kern/vfs_syscalls.c:1203
#12 0xc0292e94 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134960050, tf_esi = 135049216, tf_ebp = -1077938904,
tf_isp = -892461708, tf_ebx = 135057664, tf_edx = 135049216,
tf_ecx = 135057664, tf_eax = 5, tf_trapno = 12, tf_err = 2,
tf_eip = 134574035, tf_cs = 31, tf_eflags = 647, tf_esp =
-1077938964,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1150
#13 0xc02870ed in syscall_with_err_pushed ()
--
I think this wasn't the right patch, after all.
-- Terry
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ntfs and sendfile problem (corrupted data)
On Mon, 31 Dec 2001, Michal Mertl wrote: Sorry to bloat the list but I forgot to mention that the panics occur when I actually try to read from ntfs partition (after appliing pach from previous email). cd works ok but ls panics the kernel. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs and sendfile problem (corrupted data)
On Sun, 30 Dec 2001, Sheldon Hearn wrote: On Sun, 30 Dec 2001 01:53:08 +0100, Michal Mertl wrote: I have ntfs partition mounted ro on current. I can read from it without problems. But I noticed I get corrupted data (the corrupted file has right size but contains mostly zeros) when using ftpd to read them. I'm pretty sure the problem is thus in sendfile(2) and/or ntfs fs support. See also PR bin/31692, which reports simmilar problems using ftpd and smbfs. See my request for feedback, which ought to help verify that it's sendfile(2) causing the problem. I did use the goto oldway; and the problem went away. I tried to look at /sys/kern/uipc_syscalls.c sendfile implementation but it is too complex for me :-(. I tried ktrace on ftpd but only saw the call to sendfile(2). If you give me some guidance I can try to look into problem deeper. I don't have any experience in kernel debugging but would like to learn it. Ciao, Sheldon. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ntfs and sendfile problem (corrupted data)
I wrote about the issue once before but now I know more about the problem. I have ntfs partition mounted ro on current. I can read from it without problems. But I noticed I get corrupted data (the corrupted file has right size but contains mostly zeros) when using ftpd to read them. I'm pretty sure the problem is thus in sendfile(2) and/or ntfs fs support. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
weird NTFS and FTPD performance
I reinstalled my laptop with quite current current (20011126-JPSNAP) because I need to access NTFS partition and have 32bit PCCARD NIC (NTFS was just unbroken on current AFAIK). When I connect with ftp to 4.3-RELEASE using 100Mbps-FDX I can upload from NTFS partition with about 6MB/s (limited by disk - in systat I see lots of 4KB requests, disk usage about 90%). When connecting from 4.3 to FTPD running on current I get 7MB downloading from UFS slice and 1MB for NTFS partition! Systat show lots of 244KB requests (totalling in 22MB/s - nonsense on this disk). I expect the problem is in NTFS but there must be something important in a way ftpd reads files to serve. I can give you all the info you would need. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
