Re: Logitech iFeel Optical USB Mouse cannot be attached.
The following is the output of usbdevs -v # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), VIA(0x), rev 0x0100 port 1 powered port 2 powered This is with the mouse attached? If it doesn't even show up, that would point towards faulty hardware... The mouse has already attached when execute usbdevs and I can use this mouse in both Windows and Linux without any problem. With reference with the dmesg output attached, I guess the mouse is attached in usb1 but I cannot confirm if it is true since I am only a newbie. However, the usbdevs only list /dev/usb0 but no usb1. I found there is no device usb1 in /dev so I tried to create the device node usb1 but usbdevs still only list /dev/usb0 but no usb1. Regards, Raman Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-PRERELEASE #0: Sun Dec 23 01:55:47 HKT 2001 root@:/usr/obj/usr/src/sys/STABLE_DEBUG Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (1109.89-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044b18,AMIE,DSP,3DNow! real memory = 536788992 (524208K bytes) avail memory = 518246400 (506100K bytes) Preloaded elf kernel kernel at 0xc0389000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 9 entries at 0xc00f1750 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia model 0110 graphics accelerator at 0.0 irq 11 isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 9 at device 4.2 on pci0 uhci0: LegSup = 0x003b uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 9 at device 4.3 on pci0 uhci1: LegSup = 0x0010 uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci_device_request: not done, ii=0xc104f680 uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered uhci_device_intr_transfer: not done, ii=0xc104f620 uhci_waitintr: timeout uhci_idone: error, addr=3, endpt=0x00, status 0x50BABBLE,STALLED uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 ums0: Logitech, Inc. iFeel Mouse, rev 1.00/1.01, addr 3, iclass 3/1 uhci_waitintr: timeout usbd_transfer_cb: short transfer 074 device_probe_and_attach: ums0 attach returned 6 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 04 uhci_waitintr: timeout usbd_transfer_cb: short transfer 04 chip1: VIA 82C686 ACPI interface at device 4.4 on pci0 rl0: RealTek 8139 10/100BaseTX port 0xa400-0xa4ff mem 0xd580-0xd58000ff irq 9 at device 9.0 on pci0 rl0: Ethernet address: 00:50:ff:60:0b:b8 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xa000-0xa01f irq 5 at device 10.0 on pci0 pci0: unknown card (vendor=0x104c, dev=0x8020) at 13.0 irq 9 atapci1: Promise ATA100 controller port 0x8000-0x803f,0x8400-0x8403,0x8800-0x8807,0x9000-0x9003,0x9400-0x9407 mem 0xd400-0xd401 irq 10 at device 17.0 on pci0 ata2: at 0x9400 on atapci1 ata3: at 0x8800 on atapci1 orm0: Option ROMs at iomem 0xc-0xcbfff,0xcc000-0xc,0xd-0xd27ff on isa0 fdc0: NEC 72065B or clone 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: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port
Junior Kernel Hacker Task: ccdinit stack usage.
sys/dev/ccd/ccd.c:ccdinit() has a couple of very large items on the stack. Rewrite ccdinit() to allocate them with MALLOC(9) instead. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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 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. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker Task: ccdinit stack usage.
Hello,
On 12:23+0100, Dec 30, 2001, Poul-Henning Kamp wrote:
sys/dev/ccd/ccd.c:ccdinit() has a couple of very large items on
the stack.
Rewrite ccdinit() to allocate them with MALLOC(9) instead.
tmppath is a rather big one but I can't find the second item. What
about this patch:
Index: ccd.c
===
RCS file: /home/ncvs/src/sys/dev/ccd/ccd.c,v
retrieving revision 1.95
diff -u -r1.95 ccd.c
--- ccd.c 17 Nov 2001 00:46:08 - 1.95
+++ ccd.c 30 Dec 2001 12:15:25 -
@@ -394,7 +394,7 @@
int maxsecsize;
struct partinfo dpart;
struct ccdgeom *ccg = cs-sc_geom;
- char tmppath[MAXPATHLEN];
+ char *tmppath = NULL;
int error = 0;
#ifdef DEBUG
@@ -414,6 +414,7 @@
*/
maxsecsize = 0;
minsize = 0;
+ MALLOC(tmppath, char *, MAXPATHLEN, M_DEVBUF, M_WAITOK);
for (ix = 0; ix cs-sc_nccdisks; ix++) {
vp = cs-sc_vpp[ix];
ci = cs-sc_cinfo[ix];
@@ -422,7 +423,7 @@
/*
* Copy in the pathname of the component.
*/
- bzero(tmppath, sizeof(tmppath));/* sanity */
+ bzero(tmppath, MAXPATHLEN); /* sanity */
if ((error = copyinstr(cpaths[ix], tmppath,
MAXPATHLEN, ci-ci_pathlen)) != 0) {
#ifdef DEBUG
@@ -487,6 +488,8 @@
ci-ci_size = size;
cs-sc_size += size;
}
+
+ FREE(tmppath, M_DEVBUF);
/*
* Don't allow the interleave to be smaller than
--
Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer
phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Fw: Logitech iFeel Optical USB Mouse cannot be attached.
The following is the output of usbdevs -v # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), VIA(0x), rev 0x0100 port 1 powered port 2 powered This is with the mouse attached? If it doesn't even show up, that would point towards faulty hardware... The mouse has already attached when execute usbdevs and I can use this mouse in both Windows and Linux without any problem. With reference with the dmesg output attached, I guess the mouse is attached in usb1 but I cannot confirm if it is true since I am only a newbie. However, the usbdevs only list /dev/usb0 but no usb1. I found there is no device usb1 in /dev so I tried to create the device node usb1 but usbdevs still only list /dev/usb0 but no usb1. Sorry, usbdevs has shown usb1 after I have create the device node usb1. the following is the output of usbdevs. # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), VIA(0x), rev 0x0100 port 1 powered port 2 powered Controller /dev/usb1: addr 1: self powered, config 1, UHCI root hub(0x), VIA(0x), rev 0x0100 port 1 powered Dec 30 19:47:44 /kernel: uhci_device_request: not done, ii=0xc104f680 Dec 30 19:47:44 /kernel: uhci_device_request: not done, ii=0xc104f680 Dec 30 19:47:49 /kernel: uhci_timeout: ii=0xc104f680 Dec 30 19:47:49 /kernel: uhci_timeout: ii=0xc104f680 Dec 30 19:47:49 /kernel: uhci_device_request: not done, ii=0xc104f680 Dec 30 19:47:49 /kernel: uhci_device_request: not done, ii=0xc104f680 port 2 addr 2: self powered, config 1, product 0x9254(0x9254), Alcor Micro, Inc.(0x058f), rev 0x0100 port 1 powered Dec 30 19:47:54 /kernel: uhci_timeout: ii=0xc104f680 Dec 30 19:47:54 /kernel: uhci_timeout: ii=0xc104f680 Dec 30 19:47:54 /kernel: uhci_device_request: not done, ii=0xc104f600 Dec 30 19:47:54 /kernel: uhci_device_request: not done, ii=0xc104f600 Dec 30 19:47:59 /kernel: uhci_timeout: ii=0xc104f600 Dec 30 19:47:59 /kernel: uhci_timeout: ii=0xc104f600 Dec 30 19:47:59 /kernel: uhci_device_request: not done, ii=0xc104f600 Dec 30 19:47:59 /kernel: uhci_device_request: not done, ii=0xc104f600 port 2 addr 3: low speed, power 500 mA, config 1, iFeel Mouse(0xc030), Logitech, Inc.(0x046d), rev 0x0101 port 3 disabled port 4 disabled # Dec 30 19:48:04 /kernel: uhci_timeout: ii=0xc104f600 Dec 30 19:48:04 /kernel: uhci_timeout: ii=0xc104f600 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-PRERELEASE #0: Sun Dec 23 01:55:47 HKT 2001 root@:/usr/obj/usr/src/sys/STABLE_DEBUG Timecounter i8254 frequency 1193182 Hz CPU: AMD Athlon(tm) Processor (1109.89-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044b18,AMIE,DSP,3DNow! real memory = 536788992 (524208K bytes) avail memory = 518246400 (506100K bytes) Preloaded elf kernel kernel at 0xc0389000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 9 entries at 0xc00f1750 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia model 0110 graphics accelerator at 0.0 irq 11 isab0: VIA 82C686 PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 9 at device 4.2 on pci0 uhci0: LegSup = 0x003b uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 9 at device 4.3 on pci0 uhci1: LegSup = 0x0010 uhci_run: setting run=0 uhci_run: done cmd=0x80 sts=0x20 uhci_run: setting run=1 uhci_run: done cmd=0x81 sts=0x0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci_device_request: not done, ii=0xc104f680 uhub2: ALCOR Generic USB Hub, class 9/0, rev 1.10/1.00, addr 2 uhub2: 4 ports with 4 removable, self powered uhci_device_intr_transfer: not done, ii=0xc104f620 uhci_waitintr: timeout uhci_idone: error, addr=3, endpt=0x00, status 0x50BABBLE,STALLED uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 uhci_waitintr: timeout usbd_transfer_cb: short transfer 01 ums0: Logitech, Inc. iFeel Mouse, rev 1.00/1.01, addr 3,
Re: Junior Kernel Hacker Task: ccdinit stack usage.
[Chad David copied for last comment in message.] On Sun, 30 Dec 2001 15:28:23 +0300, Maxim Konovalov wrote: sys/dev/ccd/ccd.c:ccdinit() has a couple of very large items on the stack. Rewrite ccdinit() to allocate them with MALLOC(9) instead. tmppath is a rather big one but I can't find the second item. What about this patch: I think the others are the partinfo and ccdgeom structures. Note that you don't need to (and shouldn't as per style(9)) initialize tmppath to NULL. Also, your bzero() is unnecessary if you use the M_ZERO flag to MALLOC(9). As an aside, what's the undocumented M_DEVBUF flag for? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker Task: ccdinit stack usage.
On Sun, 30 Dec 2001 16:45:31 +0300, Maxim Konovalov wrote: struct partinfo holds only two pointers, ccg is a pointer too. I got confused with partinfo and disklabel, and didn't actually check ccg. *blush* Note that you don't need to (and shouldn't as per style(9)) initialize tmppath to NULL. Do you mean: : Be careful to not obfuscate the code by initializing variables : in the declarations. Use this feature only thoughtfully. DO NOT : use function calls in initializers. or something else? Yes, that. Bruce Evans will probably want tmppath initialized to NULL near the top of the function's code, rather than in the declarations. :-) man 9 malloc: : A type is defined using the malloc_type_t typedef via the : MALLOC_DECLARE() and MALLOC_DEFINE() macros. Take a look at /usr/src/sys/sys/malloc.h. That only tells me where it comes from, not when I'd want to use it. :-) What about this one: It's probably worth giving Poul-Henning time to wake up. ;-) Ciao, Sheldon. 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
Re: ntfs and sendfile problem (corrupted data)
On Sun, 30 Dec 2001 15:47:45 +0100, Michal Mertl wrote: 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've added your feedback to the audit trail of PR bin/31692, thanks. 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. No idea. I was just trying to narrow this down so we know who to nag. This smells like one of those things someone like dillon or bmilekic could fix. Gents, any takers? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
msdosfs_lookup returns EINVAL, not ENOENT
Whilst poking around on my msdosfs (trying to find an MP3 I thought I had), I discovered that, if there are no files matching foo*, ls foo* will return the wrong error. msdosfs: $ ls foo* ls: foo*: Invalid argument ufs: $ ls foo* ls: foo*: No such file or directory Using strace tracked this down to lstat of foo* returning EINVAL, which would appear to be incorrect, as EINVAL is not listed as a possible error for lstat. Now, since I'm not familar with the innards of freebsd's fs code, here is where I get a little bit lost. I _think_ I've tracked down the source of the error to the point where unix2dosfn is called in msdosfs_lookup, which would be expected, since '*' is an invalid character in msdos filenames, but is fine for ufs. The call on line 152 of msdosfs_lookup.c appears to be the one causing the current problem, but I'm not sure if simply replacing EINVAL with ENOENT would affect things other than lstat. However, I'm also not sure if the behaviour of the other two calls is correct. OTOH, I'm not sure what syscalls are supposed to return in the case of an invalid character in a filename. e.g. touch foo\\ fails with EINVAL currently, yet open(2) states EINVAL means you have used an invalid combination of O_RDONLY, O_WRONLY, and O_RDWR. But no error is listed in the manpage for an invalid filename, other than ENAMETOOLONG, which is clearly inappropriate. Perhaps the correct fix would just be to document the use of EINVAL? -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be msg33327/pgp0.pgp Description: PGP signature
Re: Junior Kernel Hacker Task: ccdinit stack usage.
In message [EMAIL PROTECTED], Maxim Konovalov wr ites: tmppath is a rather big one but I can't find the second item. What about this patch: I think the others are the partinfo and ccdgeom structures. struct partinfo holds only two pointers, ccg is a pointer too. I meant partinfo, but I hadn't looked at it in enough detail to notice how small it actually was. My fault. As an aside, what's the undocumented M_DEVBUF flag for? It's a catch-all malloc bucket for things in drivers which are not worth allocating their own bucket for. M_TEMP is a similar catch-all bucket for which I belive the rule-of-thumb is that nothing should remain allocated by the time we return to userland. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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, Dec 30, 2001 at 05:01:41PM +0200, Sheldon Hearn wrote: 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. No idea. I was just trying to narrow this down so we know who to nag. This smells like one of those things someone like dillon or bmilekic could fix. Gents, any takers? It would be probably relatively easy to reproduce if someone could knock together instructions on how to make a ntfs filesystem without WinNT. Either that or dd an image of a small filesystem and put it up for ftp. What other filesystems have people seen the problem with? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker Task: ccdinit stack usage.
In message [EMAIL PROTECTED], Maxim Konovalov wr ites: Ohh and I forgot: Thanks for the patch! Tested Committed :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[PATCH] Re: ntfs and sendfile problem (corrupted data)
On Sun, Dec 30, 2001 at 05:01:41PM +0200, Sheldon Hearn wrote:
On Sun, 30 Dec 2001 15:47:45 +0100, Michal Mertl wrote:
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've added your feedback to the audit trail of PR bin/31692, thanks.
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.
No idea. I was just trying to narrow this down so we know who to nag.
This smells like one of those things someone like dillon or bmilekic
could fix. Gents, any takers?
I don't know if this is correct, but I find the usage of cnt for
the loop to be very suspicious. Could you try this patch (against
-CURRENT, but should apply to -STABLE)?
Consider that sendfile may be executed many times and cnt will only
be the value of how much was written that last iteration. Therefore,
you need to check whether the *entire* file has been written. And, I
would wonder with a network-based FS, it would potentially take
multiple sendfile(2) calls - therefore the check against cnt is
invalid.
And, of course, ftpd.c isn't built against libc_r. Otherwise,
I'd say to upgrade your kernel. Alfred got the libc_r sendfile
working again a few weeks ago. -- justin
--- libexec/ftpd/ftpd.c.old Mon Nov 19 13:52:03 2001
+++ libexec/ftpd/ftpd.c Sun Dec 30 11:33:26 2001
@@ -1811,7 +1811,7 @@
len = filesize;
err = cnt = offset = 0;
- while (err != -1 cnt filesize) {
+ while (err != -1 len 0) {
err = sendfile(filefd, netfd, offset, len,
(struct sf_hdtr *) NULL, cnt, 0);
byte_count += cnt;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ntfs and sendfile problem (corrupted data)
Well, we have a problem here. smbfs is allowing VOBJBUF to be set
on its vnodes. This creates a backing VM object that smbfs never
uses and makes sendfile() believe that it can do UIO_NOCOPY uio's on
smbfs vnodes.
Michal, please try the following kernel patch and test it with the
normal ftpd (that tries to use sendfile()). Also test it with any
other programs you run on smbfs mounts. With this patch sendfile()
should now recognize that the filesystem does not support VMIO and
return an error, causing ftpd to use the old method automatically.
Unfortunately this patch creates another problem. smbfs() partially
worked with mmap() due to creating the backing object, and the
default pager ops can even read smbfs data into the backing object.
But data dirtied by the mmap() will likely not get written out and
there is no coherency between read() and mmap(). In otherwords, it
only 'kinda' supports mmap().
I believe the correct solution is to not support mmap() at all (or,
alternatively, correctly support mmap() which would be a lot of
work considering how minimal smbfs is).
Another possible solution would be to change sendfile() to attempt
to do a VOP_BMAP() or something like that, to determine whether
UIO_NOCOPY read operations are legal or not. Or we could introduce
a new VOP call to return whether it is legal to do a UIO_NOCOPY
read operation on the VM object's backing store.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:
:On Sun, 30 Dec 2001 15:47:45 +0100, Michal Mertl wrote:
:
: 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 :-(.
:..
Index: fs/smbfs/smbfs_vnops.c
===
RCS file: /home/ncvs/src/sys/fs/smbfs/smbfs_vnops.c,v
retrieving revision 1.2.2.4
diff -u -r1.2.2.4 smbfs_vnops.c
--- fs/smbfs/smbfs_vnops.c 20 Dec 2001 16:11:49 - 1.2.2.4
+++ fs/smbfs/smbfs_vnops.c 30 Dec 2001 20:01:43 -
@@ -84,6 +84,7 @@
static int smbfs_pathconf(struct vop_pathconf_args *ap);
static int smbfs_advlock(struct vop_advlock_args *);
static int smbfs_getextattr(struct vop_getextattr_args *ap);
+static int smbfs_createvobject(struct vop_createvobject_args *ap);
vop_t **smbfs_vnodeop_p;
static struct vnodeopv_entry_desc smbfs_vnodeop_entries[] = {
@@ -92,6 +93,7 @@
{ vop_advlock_desc,(vop_t *) smbfs_advlock },
{ vop_bmap_desc, (vop_t *) smbfs_bmap },
{ vop_close_desc, (vop_t *) smbfs_close },
+ { vop_createvobject_desc, (vop_t *) smbfs_createvobject },
{ vop_create_desc, (vop_t *) smbfs_create },
{ vop_fsync_desc, (vop_t *) smbfs_fsync },
{ vop_getattr_desc,(vop_t *) smbfs_getattr },
@@ -1331,3 +1333,15 @@
}
return 0;
}
+
+static int
+smbfs_createvobject(ap)
+struct vop_createvobject_args /* {
+struct vnode *vp;
+struct ucred *cred;
+struct proc *p;
+} */ *ap;
+{
+ return(0);
+}
+
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ntfs and sendfile problem (corrupted data)
Oops, sorry, that patch was for smbfs on -stable. Not -current. ntfs has a similar problem. It implements VOP_BMAP but fakes it, and ntfs_read() doesn't *USE* the buffer cache, so again sendfile() believes that a UIO_NOCOPY read will work when it won't. And, again there is no coherency. This is even worse then what smbfs() does. I think the solution for ntfs is the same as for smbfs... create a vop_createvobject tag that does not set VOBJBUF and, as with smbfs, this will cause mmap() to fail. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE changes available
On Mon, 24 Dec 2001, Glenn Gombert wrote:
In case anyone is interested I have put a set of patched source code
files from the link below on my FreeBSD Web Page at:
freebsd.imatowns.com/kse3
There are the patched source code files,individual patches (from the
link below) and the un-patched source files in three differnet directories:
/patched-src
/patches
/unpatched-src
I have not tried to compile these yet, I just finished getting the source
files patched :)
As someone mentionned, the up-to-date KSE tree is available
through cvsup10 but I don't know the collection.
maybe peter can remind us how to get it.
Julian
p.s. I'm quite close to needing those syscall stubs :-) (a few days)
Glenn G.
Julian Elischer [EMAIL PROTECTED] wrote:
The latest round of KSE changes are available from
http://www.freebsd.org/~julian/thediff
These changes represent a work in progress.
Basically the state is:
GENERIC compiles
(I don't know yet if it runs but I doubt it.)
The following changes have been made:
The 'thread' structure is no longer a built-in part of the proc structure.
There is an infrastructure to independently crfeate and reap threads.
The infrastructure is used to create and destroy the 'usual' single
thread
associated with each process. It should eventually be used to create
more
threads per process..
The 'state' variable associated with the process has been raped and
now each thread, and process and KSE has it's own state.
This last part is the bit that is broken because a LOT of the kernel
doesn't expect the state of a thread to be spread across several
structures.
For example:
switch (p-p_stat) {
case SRUN:
...
case SSTOP:
..
has to be completely rewritten because
SRUN is a per-thread property
and is accessed as:
FOREACH_THREAD_IN_PROC(p, td) {
switch(td-td_state) {
case TDS_RUNNING:
case TDS_RUNQ:
case TDS_SLP:
...
}
...
}
wheras STOP is still a per-process state.
obviously any code that tries to assume the same scope for these tow
states will break violently in the new code.
I have replaced some of the logic where there seems to be a simple
answer,
but there are plenty of places where the answer is not clear.
Such places include signal delivery,
selection of process (thread?) to deliver a signal to,
collection of scheduling statistics,
handling FORK run by one of several threads,
handling EXIT run by one of several threads,
handling when the user types ^Z and suspends the process.
If anyone is feeling adventurous they can stat with the code that is
there
and start fixing things :-)
send me patches but let me know ahead of time what you will be doing
so we don't duplicate, and so I can send you notes on where I'm going
in
that part..
I'll be working on the scheduler for the next few days I think.
Note: if ((p-p_flag P_KSES) == 0) a process should act exactly as
it
does now.. :-)
REGARDS JULIAN
(bloody capslock key)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
__
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: P4 Access For Latest KSE Change(s)
Here is an e-mail from Peter describing how to pull down the latest changes from cvsup10 if anyone is interested :) OK, what you want then is: collection=p4-cvs-kse release=cvs (tag=. if you're using checkout mode) That will pull down src/sys and a few other things. You can build that standalone or symlink it into a complete tree etc. You're only really intersted in src/sys at this point.. the libkvm, gdb etc stuff hasn't been updated there, but will be later. Cheers, Peter Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]All of this is for nothing if we don't go to the stars - JMS/B5 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 Sunday 30 December 2001 5:27 pm, David Malone wrote: On Sun, Dec 30, 2001 at 05:01:41PM +0200, Sheldon Hearn wrote: 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. No idea. I was just trying to narrow this down so we know who to nag. This smells like one of those things someone like dillon or bmilekic could fix. Gents, any takers? It would be probably relatively easy to reproduce if someone could knock together instructions on how to make a ntfs filesystem without WinNT. Do you have a copy of PowerQuest Partiton Magic? I would guess you do not as you'd would have thought of that already otherwise, but I think its worth a mention. Either that or dd an image of a small filesystem and put it up for ftp. What other filesystems have people seen the problem with? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Dominic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs and sendfile problem (corrupted data)
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. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntfs and sendfile problem (corrupted data)
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. FreeBSD -current uses external mbufs. Previous versions did not. It's the new mbuf code. Look at how it gets the things that it points to. The problem is that the references are transient, and it assumes they aren't. I don't have a ready fix. You can revert the sendfile code pretty easily to the 4.3 version. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Win a CD/Cassette Home Stereo Player.
Total Care Laboratories offers a line of personal care products for men who want to maintain a natural, healthy and professional look. If your hair looks dry, dull or your having shaving problems then you need to visit www.blacpro.com Also register to win a CD/Cassette player. If you would like for us to remove you from this list type REMOVE in the subject line. (Not in The Body) and reply back to us. You will then be promptly and permanently removed from our list. Sincerely, William Franks CEO
Re: P4 Access For Latest KSE Change(s)
For anyone who cares, you can also check out various other in-progress projects including: TrustedBSD mandatory access control: p4-cvs-trustedbsd-mac Trustedbsd POSIX.1e capabilities: p4-cvs-trustedbsd-cap Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 30 Dec 2001, Glenn Gombert wrote: Here is an e-mail from Peter describing how to pull down the latest changes from cvsup10 if anyone is interested :) OK, what you want then is: collection=p4-cvs-kse release=cvs (tag=. if you're using checkout mode) That will pull down src/sys and a few other things. You can build that standalone or symlink it into a complete tree etc. You're only really intersted in src/sys at this point.. the libkvm, gdb etc stuff hasn't been updated there, but will be later. Cheers, Peter Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
