Re: em0, polling performance, P4 2.8ghz FSB 800mhz
You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. Does that really help? If so, we need to optimize the syncache. :( I know that if I rate shape the setup traffic, it helps. DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
On Sat, 28 Feb 2004, Don Bowman wrote: > You could use ipfw to limit the damage of a syn flood, e.g. > a keep-state rule with a limit of ~2-5 per source IP, lower the > timeouts, increase the hash buckets in ipfw, etc. This would > use a mask on src-ip of all bits. > something like: > allow tcp from any to any setup limit src-addr 2 > > this would only allow 2 concurrent TCP sessions per unique > source address. Depends on the syn flood you are expecting > to experience. You could also use dummynet to shape syn > traffic to a fixed level i suppose. Does that really help? If so, we need to optimize the syncache. :( Mike "Silby" Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
... > > > > > > You may need to increase the MAX_RXD inside your em driver > to e.g. 512. > > I didn't know if my card had a buffer bigger than the default > 256. I can > increase it, but I didn't know how to determine how big a MAX_RXD my > card would support. When the system was under load, it was generating > 2xHZ clock ticks (2000 when HZ was 1000) is that normal? max_rxd is not a function of the card. its the system ram you devote to dma buffers. Too big will cause problems since it will flush through the cache etc. you should get (vmstat -i) a clk rate that exactly matches hz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
Don Bowman wrote: It was kindly pointed out that I didn't including the symptoms of the problem: Without polling on, I get 70+% interrupt load, and I get live lock. With polling on, I start getting huge amounts of input errors, packet loss, and general unresponsiveness to the network. The web server on it doesn't respond though it occassionally will open the connection, just not respond. accept_filter on/off makes no difference. I have read other posts that say em systems can more >200kpps without serious incident. Thanks in advance, DJ You may need to increase the MAX_RXD inside your em driver to e.g. 512. I didn't know if my card had a buffer bigger than the default 256. I can increase it, but I didn't know how to determine how big a MAX_RXD my card would support. When the system was under load, it was generating 2xHZ clock ticks (2000 when HZ was 1000) is that normal? With similar system, em can handle ~800Kpps of bridging. What settings did you use? Your earlier email showed a very large number of RST messages, which makes me suspect the blackhole actually wasn't enabled. Not exactly sure what you're trying to do here. It sounds like you are trying to generate a SYN flood on port 80, and your listen queue is backing up. You've increased kern.ipc.somaxconn? Does your application specify a fixed listen queue depth? Could it be increased? Are you using apache as the server? Could you use a kqueue-enabled one like thttpd? Using apache, might go to squid or thttpd. Didn't think it should make a big deal. Increased somaxconn. Basically the system is getting hammered (after all filtering at the router) with valid get requests on port 80. Have you checked net.inet.ip.intr_queue_drops? If its showing >0, check net.inet.ip.intr_queue_maxlen, perhaps increase it. net.inet.ip.intr_queue_maxlen: 500 net.inet.ip.intr_queue_drops: 0 p1003_1b.sigqueue_max: 0 No intr drops. Have you sufficient mbufs and clusters? netstat -m. 1026/5504/262144 mbufs in use (current/peak/max): 1026 mbufs allocated to data 1024/5460/65536 mbuf clusters in use (current/peak/max) 12296 Kbytes allocated to network (6% of mb_map in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines mbufs look fine. If you want to spend more time in kernel, perhaps change kern.polling.user_frac to 10? I'll do that. I might have HZ @ 2500 as well. You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 This is a great idea. We were trapping those who crossed our connection thresholds and blackholing them upstream (automatically, with a script). this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. now... this will switch the DoS condition to elsewhere in the kernel, and it might not win you anything. net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_syn_lifetime=5 net.inet.ip.fw.dyn_max=32000 might be called for if you try that approach. I see where that should get us. We'll see. Thanks! DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
> It was kindly pointed out that I didn't including the symptoms of the > problem: > > > Without polling on, I get 70+% interrupt load, and I get live lock. > > With polling on, I start getting huge amounts of input errors, packet > loss, and general unresponsiveness to the network. The web > server on it > doesn't respond though it occassionally will open the > connection, just > not respond. accept_filter on/off makes no difference. I have > read other > posts that say em systems can more >200kpps without serious incident. > > Thanks in advance, > > DJ You may need to increase the MAX_RXD inside your em driver to e.g. 512. With similar system, em can handle ~800Kpps of bridging. Your earlier email showed a very large number of RST messages, which makes me suspect the blackhole actually wasn't enabled. Not exactly sure what you're trying to do here. It sounds like you are trying to generate a SYN flood on port 80, and your listen queue is backing up. You've increased kern.ipc.somaxconn? Does your application specify a fixed listen queue depth? Could it be increased? Are you using apache as the server? Could you use a kqueue-enabled one like thttpd? Have you checked net.inet.ip.intr_queue_drops? If its showing >0, check net.inet.ip.intr_queue_maxlen, perhaps increase it. Have you sufficient mbufs and clusters? netstat -m. If you want to spend more time in kernel, perhaps change kern.polling.user_frac to 10? I might have HZ @ 2500 as well. You could use ipfw to limit the damage of a syn flood, e.g. a keep-state rule with a limit of ~2-5 per source IP, lower the timeouts, increase the hash buckets in ipfw, etc. This would use a mask on src-ip of all bits. something like: allow tcp from any to any setup limit src-addr 2 this would only allow 2 concurrent TCP sessions per unique source address. Depends on the syn flood you are expecting to experience. You could also use dummynet to shape syn traffic to a fixed level i suppose. now... this will switch the DoS condition to elsewhere in the kernel, and it might not win you anything. net.inet.ip.fw.dyn_buckets=16384 net.inet.ip.fw.dyn_syn_lifetime=5 net.inet.ip.fw.dyn_max=32000 might be called for if you try that approach. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
And this was picked up in the messages log: /kernel: stray irq 7 last message repeated 2 times /kernel: too many stray irq 7's; not logging any more DJ Don Bowman wrote: I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is >90% idle even under the worst of the attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
Don Bowman wrote: I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is >90% idle even under the worst of the attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). I'd like to know more about the CPU time idea. I have net.inet.udp.blackhole=2 and net.inet.tcp.blackhole=2 because I saw a lot of dstunreachable packets out. The system can hyperthread, but I thought the singlethreading of polling might have been an issue, so I recompiled the kernel without SMP. DJ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: em0, polling performance, P4 2.8ghz FSB 800mhz
It was kindly pointed out that I didn't including the symptoms of the problem: Without polling on, I get 70+% interrupt load, and I get live lock. With polling on, I start getting huge amounts of input errors, packet loss, and general unresponsiveness to the network. The web server on it doesn't respond though it occassionally will open the connection, just not respond. accept_filter on/off makes no difference. I have read other posts that say em systems can more >200kpps without serious incident. Thanks in advance, DJ Deepak Jain wrote: I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is >90% idle even under the worst of the attack. What am I doing wrong? Thanks, DJ #sysctl -a |grep hz kern.clockrate: { hz = 1000, tick = 1000, tickadj = 1, profhz = 1024, stathz = 1 28 } #sysctl -a |grep polling kern.polling.burst: 544 kern.polling.each_burst: 30 kern.polling.burst_max: 550 kern.polling.idle_poll: 1 kern.polling.poll_in_trap: 0 kern.polling.user_frac: 50 kern.polling.reg_frac: 30 kern.polling.short_ticks: 44151 kern.polling.lost_polls: 84925 kern.polling.pending_polls: 0 kern.polling.residual_burst: 0 kern.polling.handlers: 1 kern.polling.enable: 1 kern.polling.phase: 0 kern.polling.suspect: 39272 kern.polling.stalled: 5 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.9-RELEASE #8: Sat Feb 28 23:42:41 GMT 2004 Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.38-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Hyperthreading: 2 logical CPUs real memory = 2147418112 (2097088K bytes) avail memory = 2085978112 (2037088K bytes) Preloaded elf kernel "kernel" at 0xc04fa000. Warning: Pentium 4 CPU: PSE disabled Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 12 entries at 0xc00fdea0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 em0: port 0xb000-0xb01f mem 0xf300-0xf301 irq 12 at device 1.0 on pci2 em0: Speed:N/A Duplex:N/A uhci0: port 0xcc00-0xcc1f irq 11 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc000-0xc01f irq 3 at d evice 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xc400-0xc41f irq 12 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xc800-0xc81f irq 11 at device 29.3 on pci0 usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at 29.7 irq 7 pcib3: at device 30.0 on pci0 pci3: on pcib3 ahd0: port 0x9400-0x94ff,0x9000-0x90ff m em 0xf202-0xf2021fff irq 11 at device 0.0 on pci3 aic7901A: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs pci3: (vendor=0x105a, dev=0x3373) at 3.0 irq 10 pci3: at 7.0 irq 11 pci3: (vendor=0x8086, dev=0x1051) at 8.0 irq 5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0 x7 irq 0 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: (vendor=0x8086, dev=0x24d3) at 31.3 irq 9 orm0: at iomem 0xc-0xc7fff,0xc8000-0xd17ff on isa0 pmtimer0 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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: parallel port not found. DUMMYNET initialized (011031) IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing En
RE: em0, polling performance, P4 2.8ghz FSB 800mhz
> I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 > ethernet connected to a Cisco, both sides are locked to 1000/FD. > > The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, > etc. After > only a few minutes of run time under an attack ~90,000 pps. > The attack > has been limited at the router to JUST incoming TCP port 80 inbound > traffic. I don't know why the machine is having such a hard > time under > the load. The cpu shows it is >90% idle even under the worst of the > attack. What am I doing wrong? I think there's a problem with CPU time not getting properly accounted for in device polling, so it may be busier than you think. For this scenario, i would set net.inet.tcp.blackhole=2. You might be spending a lot of time creating the ICMP unreachable messages, rather than in the network driver (where device polling would help). --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em0, polling performance, P4 2.8ghz FSB 800mhz
I have a machine running 4.9. P4 2.8Ghz, 800mhz bus, Intel PRO/1000 ethernet connected to a Cisco, both sides are locked to 1000/FD. The kernel has HZ=1000, and DEVICE_POLLING, IPFW, DUMMYNET, etc. After only a few minutes of run time under an attack ~90,000 pps. The attack has been limited at the router to JUST incoming TCP port 80 inbound traffic. I don't know why the machine is having such a hard time under the load. The cpu shows it is >90% idle even under the worst of the attack. What am I doing wrong? Thanks, DJ #sysctl -a |grep hz kern.clockrate: { hz = 1000, tick = 1000, tickadj = 1, profhz = 1024, stathz = 1 28 } #sysctl -a |grep polling kern.polling.burst: 544 kern.polling.each_burst: 30 kern.polling.burst_max: 550 kern.polling.idle_poll: 1 kern.polling.poll_in_trap: 0 kern.polling.user_frac: 50 kern.polling.reg_frac: 30 kern.polling.short_ticks: 44151 kern.polling.lost_polls: 84925 kern.polling.pending_polls: 0 kern.polling.residual_burst: 0 kern.polling.handlers: 1 kern.polling.enable: 1 kern.polling.phase: 0 kern.polling.suspect: 39272 kern.polling.stalled: 5 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.9-RELEASE #8: Sat Feb 28 23:42:41 GMT 2004 Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2806.38-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Hyperthreading: 2 logical CPUs real memory = 2147418112 (2097088K bytes) avail memory = 2085978112 (2037088K bytes) Preloaded elf kernel "kernel" at 0xc04fa000. Warning: Pentium 4 CPU: PSE disabled Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 12 entries at 0xc00fdea0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 em0: port 0xb000-0xb01f mem 0xf300-0xf301 irq 12 at device 1.0 on pci2 em0: Speed:N/A Duplex:N/A uhci0: port 0xcc00-0xcc1f irq 11 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc000-0xc01f irq 3 at d evice 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xc400-0xc41f irq 12 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xc800-0xc81f irq 11 at device 29.3 on pci0 usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at 29.7 irq 7 pcib3: at device 30.0 on pci0 pci3: on pcib3 ahd0: port 0x9400-0x94ff,0x9000-0x90ff m em 0xf202-0xf2021fff irq 11 at device 0.0 on pci3 aic7901A: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs pci3: (vendor=0x105a, dev=0x3373) at 3.0 irq 10 pci3: at 7.0 irq 11 pci3: (vendor=0x8086, dev=0x1051) at 8.0 irq 5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0-0x3,0-0x7,0-0x3,0-0 x7 irq 0 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: (vendor=0x8086, dev=0x24d3) at 31.3 irq 9 orm0: at iomem 0xc-0xc7fff,0xc8000-0xd17ff on isa0 pmtimer0 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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: parallel port not found. DUMMYNET initialized (011031) IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabl ed da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) em0: Link is up 1000 Mbps Full Duplex Limiting closed port RST response from 76352 to 200 packets per second Limiting closed port RST response from 75963 to 200 packets per second Limiting closed port RST response from 74737 to 200 packets per second ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP.. USB MFC coming..
On Sun, 29 Feb 2004, Dmitry Morozovsky wrote: > On Fri, 27 Feb 2004, Julian Elischer wrote: > > JE> I plan to commit the MFC at http://www.josef-k.net/freebsd/ > JE> (the latest one) in the next couple of days. If you really care about > JE> USB in 4.10 you might do well to test this on your equipment, > JE> ESPECIALLY if you have unusual devices. Let me know of both successes > JE> and failures please.. If I hear nothing I won't know if it's because > JE> no-one tested it or it was just without problems.. > JE> > JE> Please also check these same devices without the patch BEFORE you let me > JE> know of any failures so that we can tell if they are truely caused by > JE> the patch.. > > Well, my main headache (SONY Clie SJ20) is now in a bit different state; before > (at 4.9p1) it failed to attach with > > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 > ucom0: init failed, STALLED > device_probe_and_attach: ucom0 attach returned 6 > ugen0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 > > now it is correctly identified (after HotSync activation) as > > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 > ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 > > Controller /dev/usb0: > addr 1: low speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev > 1.00 > port 1 powered > port 2 addr 2: low speed, self powered, config 1, Palm Handheld(0x0066), Palm, > Inc.(0x054c), rev 1.00 > > However, I still can't figure out how to sync, as dlpsh can't attach to > /dev/ucom before activatyng Sync, and never goes to the shell prompt when shouldn't it be /dev/ucom0? (assuming it exists) > statring in the middle of sync process. Googling does not help much, > unfortunately. > > Two other USB devices I have are USB Generic storage (CF reader and MP3 > player), and they seem to keep work smoothly. > > I had I/O errors and hangups with cheap MemoryStick reader before, > but do not have it by hand to quick check. Hope to check tomorrow. > I'll go ahead with the MFC but I'll try handle these reports afterwards... > Thanks for your work! > > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP.. USB MFC coming..
On Fri, 27 Feb 2004, Julian Elischer wrote: JE> I plan to commit the MFC at http://www.josef-k.net/freebsd/ JE> (the latest one) in the next couple of days. If you really care about JE> USB in 4.10 you might do well to test this on your equipment, JE> ESPECIALLY if you have unusual devices. Let me know of both successes JE> and failures please.. If I hear nothing I won't know if it's because JE> no-one tested it or it was just without problems.. JE> JE> Please also check these same devices without the patch BEFORE you let me JE> know of any failures so that we can tell if they are truely caused by JE> the patch.. Well, my main headache (SONY Clie SJ20) is now in a bit different state; before (at 4.9p1) it failed to attach with ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: init failed, STALLED device_probe_and_attach: ucom0 attach returned 6 ugen0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 now it is correctly identified (after HotSync activation) as ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 ucom0: Palm, Inc. Palm Handheld, rev 1.00/1.00, addr 2 Controller /dev/usb0: addr 1: low speed, self powered, config 1, UHCI root hub(0x), Intel(0x), rev 1.00 port 1 powered port 2 addr 2: low speed, self powered, config 1, Palm Handheld(0x0066), Palm, Inc.(0x054c), rev 1.00 However, I still can't figure out how to sync, as dlpsh can't attach to /dev/ucom before activatyng Sync, and never goes to the shell prompt when statring in the middle of sync process. Googling does not help much, unfortunately. Two other USB devices I have are USB Generic storage (CF reader and MP3 player), and they seem to keep work smoothly. I had I/O errors and hangups with cheap MemoryStick reader before, but do not have it by hand to quick check. Hope to check tomorrow. Thanks for your work! Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP.. USB MFC coming..
On Saturday 28 February 2004 16:32, you wrote: > thankyou.. I haven't looked a the PR yet but does it happen in 5.x and > 4.x? Yes, as far as I know both problems are in 4.x and 5.x . > On Sat, 28 Feb 2004, Daan Vreeken [PA4DAN] wrote: > > On Saturday 28 February 2004 02:54, Julian Elischer wrote: > > > I plan to commit the MFC at http://www.josef-k.net/freebsd/ > > > (the latest one) in the next couple of days. If you really care about > > > USB in 4.10 you might do well to test this on your equipment, > > > ESPECIALLY if you have unusual devices. Let me know of both successes > > > and failures please.. If I hear nothing I won't know if it's because > > > no-one tested it or it was just without problems.. > > > > If you have any time left on your schedule, maybe you could have a look > > at 2 pr's I have filed about the USB stack. Both problems can crash a > > system easilly and both contain a patch to fix it : > > > > kern/59290: [PATCH] attaching more than one of the same usb if_* adapters > > crashes system > > kern/51186: pointer arithmatic error in ugen.c > > > > Thanks, > > Daan Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP.. USB MFC coming..
thankyou.. I haven't looked a the PR yet but does it happen in 5.x and 4.x? On Sat, 28 Feb 2004, Daan Vreeken [PA4DAN] wrote: > On Saturday 28 February 2004 02:54, Julian Elischer wrote: > > I plan to commit the MFC at http://www.josef-k.net/freebsd/ > > (the latest one) in the next couple of days. If you really care about > > USB in 4.10 you might do well to test this on your equipment, > > ESPECIALLY if you have unusual devices. Let me know of both successes > > and failures please.. If I hear nothing I won't know if it's because > > no-one tested it or it was just without problems.. > If you have any time left on your schedule, maybe you could have a look at 2 > pr's I have filed about the USB stack. Both problems can crash a system > easilly and both contain a patch to fix it : > > kern/59290: [PATCH] attaching more than one of the same usb if_* adapters > crashes system > kern/51186: pointer arithmatic error in ugen.c > > Thanks, > Daan > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP.. USB MFC coming..
On Saturday 28 February 2004 02:54, Julian Elischer wrote: > I plan to commit the MFC at http://www.josef-k.net/freebsd/ > (the latest one) in the next couple of days. If you really care about > USB in 4.10 you might do well to test this on your equipment, > ESPECIALLY if you have unusual devices. Let me know of both successes > and failures please.. If I hear nothing I won't know if it's because > no-one tested it or it was just without problems.. If you have any time left on your schedule, maybe you could have a look at 2 pr's I have filed about the USB stack. Both problems can crash a system easilly and both contain a patch to fix it : kern/59290: [PATCH] attaching more than one of the same usb if_* adapters crashes system kern/51186: pointer arithmatic error in ugen.c Thanks, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"