Re: usb (ucom) driver code comments..?
M. Warner Losh wrote: In message: [EMAIL PROTECTED] JacobRhoden [EMAIL PROTECTED] writes: : I am trying to get a device working which uses ucom, and the ucom code has no : comments whatsoever, I am able to work bits out, I was wondering if there was : any sort of documentation whatsoever on this area? Use the source luke. However, you'll need to look closely at sys/kern/tty* as well. Looking at something like umodem that implements a ucom plug in might be useful too. You might check out the handbook too, but I think that the usb docs there don't specifically cover usb. There was also a patch posted to the -current or -hackers mailing list around about the end of May that switched 0 and 1 and made made this wort of thing work for another USB device. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[Bug c++/11735] [3.3 Regression] internal compiler error:Segmentation fault
Here about the latest bug, i was telling about ... Regards Kai -Ursprüngliche Nachricht- Von: pinskia at physics dot uc dot edu [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 31. Juli 2003 01:45 An: [EMAIL PROTECTED] Betreff: [Bug c++/11735] [3.3 Regression] internal compiler error: Segmentation fault pinskia at physics dot uc dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Additional Comments From pinskia at physics dot uc dot edu 2003-07-30 23:44 --- I can confirm this on 3.3 (20030707). And it does not seg fault in 3.2.3 and the mainline (20030730) but I do not have the time to reduce this so marking as invalid so it can be marked as According to Phil's regression hunter this is already fixed in 3.3.1 (20030729). I also cannot reproduce it on 3.3.1 (20030714). So this is fixed for 3.3.1 which should be released in the next two weeks. Since you are already using a prelease I would update your prelease. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc segfault on -CURRENT (cvs yesterday)
Kai Mosebach wrote: Trying to compile sapdb fails on a -CURRENT system build yesterday. On a system from 22.July it compiled fine. Any ideas ? This is pretty ugly, but put a space before the ::'s on that line. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Ultra ATA card doesn't seem to provide Ultra speeds.
Hello hackers! I hope someone can help me with this since you know the internals of FreeBSD much more than me. Hope it doesn't take much time. The sort of problem I'm having is this: after installing a new Ultra ATA card (it's based on Silicon Image 0680 chip by the way) although the disks start to run at UATA6 (133) mode (as seen in dmesg output or atacontrol), I see absolutely no improvement compared to WDMA2 mode they used to run previously. I still can get around 14Mb/s on dd transfers, but there has to be more? My motherboard only supports WDMA2 mode and nothing more and that's why I bought the card. Is there any trick I forgot to apply? The drive is Maxtor 120Gb Diamond Plus 9. Also, file transfers from mounted NTFS seem to be very very slow, much slower than UFS transfers, what gives (when using mkisofs for example for burning CDs)? Hope someone can shed some light on this... Z ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Buckie wrote: Hello hackers! I hope someone can help me with this since you know the internals of FreeBSD much more than me. Hope it doesn't take much time. The sort of problem I'm having is this: after installing a new Ultra ATA card (it's based on Silicon Image 0680 chip by the way) although the disks start to run at UATA6 (133) mode (as seen in dmesg output or atacontrol), I see absolutely no improvement compared to WDMA2 mode they used to run previously. I still can get around 14Mb/s on dd transfers, but there has to be more? My motherboard only supports WDMA2 mode and nothing more and that's why I bought the card. Is there any trick I forgot to apply? The drive is Maxtor 120Gb Diamond Plus 9. Also, file transfers from mounted NTFS seem to be very very slow, much slower than UFS transfers, what gives (when using mkisofs for example for burning CDs)? Hope someone can shed some light on this... Possibly, but you need to give us info so we can try to diagnose the problem it doesn't work it not enough, so please provide at least: FreeBSD version (output of uname -a) Boot log (output of dmesg) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
for me works just fine: atapci0: SiI 0680 ATA133 controller port 0xf400-0xf40f,0xf000-0xf003,0xe800-0xe807,0xe400-0xe403,0xe000-0xe007 mem 0xfedff800-0xfedff8ff irq 11 at device 17.0 on pci0 with: ad0: 19073MB Maxtor 2B020H1 [38752/16/63] at ata2-master UDMA100 on: FreeBSD 4.8-STABLE CPU: Pentium/P55C (166.19-MHz 586-class CPU) Origin = GenuineIntel Id = 0x543 Stepping = 3 Features=0x8003bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC,MMX real memory = 134217728 (131072K bytes) avail memory = 127156224 (124176K bytes) Programming 16 pins in IOAPIC #0 EISA INTCONTROL = 1e00 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 now my networks speed is 4-5 mb/sec (old speed it was 700-800 kb/sec) paul - Original Message - From: Buckie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 31, 2003 12:50 PM Subject: Ultra ATA card doesn't seem to provide Ultra speeds. Hello hackers! I hope someone can help me with this since you know the internals of FreeBSD much more than me. Hope it doesn't take much time. The sort of problem I'm having is this: after installing a new Ultra ATA card (it's based on Silicon Image 0680 chip by the way) although the disks start to run at UATA6 (133) mode (as seen in dmesg output or atacontrol), I see absolutely no improvement compared to WDMA2 mode they used to run previously. I still can get around 14Mb/s on dd transfers, but there has to be more? My motherboard only supports WDMA2 mode and nothing more and that's why I bought the card. Is there any trick I forgot to apply? The drive is Maxtor 120Gb Diamond Plus 9. Also, file transfers from mounted NTFS seem to be very very slow, much slower than UFS transfers, what gives (when using mkisofs for example for burning CDs)? Hope someone can shed some light on this... Z ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Hello again. Sorry I just forgot to provide at least a version number. Stupid me. It's FreeBSD 5.1 RELEASE and here's a dmesg output. Also, it's not that it 'doesn't work', it works, but I see no difference in speed after changing transfer modes (from WDMA2 to UDMA6) Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #10: Wed Jul 30 12:18:51 MSD 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KIT Preloaded elf kernel /boot/kernel/kernel at 0xc0465000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (200.46-MHz 686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping = 9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 201326592 (192 MB) avail memory = 190713856 (181 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 12 IOAPIC #0 intpin 17 - irq 11 IOAPIC #0 intpin 18 - irq 10 IOAPIC #0 intpin 19 - irq 15 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdd00 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371SB (PIIX3) USB controller port 0x9000-0x901f irq 15 at device 7.2 on pci0 usb0: Intel 82371SB (PIIX3) USB controller 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 ukbd0: vendor 0x099a USB Multimedia Keyboard, rev 1.10/1.01, addr 2, iclass 3/1 ums0: Kensington Kensington USB/PS2 Orbit, rev 1.10/4.00, addr 3, iclass 3/1 ums0: 2 buttons drm0: 3dfx Voodoo3 3000 port 0x9400-0x94ff mem 0xe200-0xe3ff,0xe000-0xe1ff irq 11 at device 9.0 on pci0 info: [drm] Initialized tdfx 1.0.0 20010216 on minor 0 pcm0: Creative CT5880-C port 0x9800-0x983f irq 10 at device 10.0 on pci0 pcm0: SigmaTel STAC9721/23 AC97 Codec ed0: NE2000 PCI Ethernet (RealTek 8029) port 0x9c00-0x9c1f irq 15 at device 11.0 on pci0 ed0: address 00:e0:4c:dd:23:1c, type NE2000 (16 bit) atapci1: SiI 0680 UDMA133 controller port 0xb000-0xb00f,0xac00-0xac03,0xa800-0xa807,0xa400-0xa403,0xa000-0xa007 mem 0xe400-0xe4ff irq 12 at device 12.0 on pci0 ata2: at 0xa000 on atapci1 ata3: at 0xa800 on atapci1 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sc0: System console 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 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources (port) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) Timecounters tick every 10.000 msec ad0: 9729MB ST310215A [19767/16/63] at ata0-master WDMA2 ad1: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata2-master UDMA133 acd0: CD-RW PLEXTOR CD-R PX-W4824A at ata3-master PIO4 SMP: AP CPU #1 Launched! cd0 at ata3 bus 0 target 0 lun 0 cd0: PLEXTOR CD-R PX-W4824A 1.04 Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Mounting root from ufs:/dev/ad0s2a I ran a dd: dd if=/dev/ad1 of=/dev/zero ibs=8192 ...and cancelled it after some amount of time: 2321+0 records in 37136+0 records out 19013632 bytes transferred in 27.876118 secs (682076 bytes/sec) I don't use static2 ata device numbering hence Maxtor is assigned ad1, but it would be ad4 if things were static. Experiemnting with ibs value I can get speeds of up to 16MB per second. But no more. Z SS Possibly, but you need to give us info so we can try to diagnose the SS problem it doesn't work it not enough, so please provide at least: SS FreeBSD version (output of uname -a) SS Boot log (output of dmesg) SS -Søren -- Best regards, Buckiemailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Buckie wrote: I ran a dd: dd if=/dev/ad1 of=/dev/zero ibs=8192 ...and cancelled it after some amount of time: 2321+0 records in 37136+0 records out 19013632 bytes transferred in 27.876118 secs (682076 bytes/sec) I don't use static2 ata device numbering hence Maxtor is assigned ad1, but it would be ad4 if things were static. Experiemnting with ibs value I can get speeds of up to 16MB per second. But no more. OH, you need to output to /dev/null NOT /dev/zero :) besides that, all looks OK, but you need a fairly large bs to se improvments on this (relatively slow) machine, try a bs of 1m and see if that helps, if not there is something slowing down your system.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Soeren, Heh, QNX in first RTP incarnations only had /dev/zero and I sort of get used to it. But nevermind. I've already tried large bsizes (1m and more) and /dev/null too. But I can't really get past the 16Mb/s barrier... Does machine speed really should affect the hard drive performance so much? I don't think that top showed me the processor usage on dd more than 30%, then again it might be something else... I also had a thought about measuring raw io performance, but the only way I know is dd to zero (null). I'm saying this because in... ugh... Windows I get raw io speeds of up to 60(!) Mb per second (HDTach). And that's fine but Windows doesn't want to mount any volumes off this drive if the speed is set to something more than WDMA2 (even UDMA0). It can only access it sector-by-sector, but without any problems though. Overall, the SI0680 card is a mystery! And SiliconImage is silent as well. Any other ideas as to how to measure the performance or ways to speed it up somehow or test it? Z SS OH, you need to output to /dev/null NOT /dev/zero :) SS besides that, all looks OK, but you need a fairly large bs to se improvments SS on this (relatively slow) machine, try a bs of 1m and see if that SS helps, if not there is something slowing down your system.. SS -Søren SS ___ SS [EMAIL PROTECTED] mailing list SS http://lists.freebsd.org/mailman/listinfo/freebsd-hackers SS To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best regards, Buckiemailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SNMP
I've been happily using ucd-snmp-4.2.6 for a couple of years. -- Error Code=-1 Continue? Yes | No -- Hi, I am new to SNMP. I was asked to set up SNMP agents and a manager on some of the computers in the lab. Can someone recommend some SNMP programs that I can use or a good link on the Internet? I need it for both FreeBSD and Windows machines. Thank you very much for you time. Best regards Artem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-config To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
In the last episode (Jul 31), Buckie said: Soeren, Heh, QNX in first RTP incarnations only had /dev/zero and I sort of get used to it. But nevermind. I've already tried large bsizes (1m and more) and /dev/null too. But I can't really get past the 16Mb/s barrier... What I find fascinating is that Maxtor's site never actually tells you the true throughput of that disk anywhere. http://www.maxtor.com/en/products/ata/desktop/diamondmax_plus_9/ -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
What I find fascinating is that Maxtor's site never actually tells you the true throughput of that disk anywhere. http://www.maxtor.com/en/products/ata/desktop/diamondmax_plus_9/ Almost none of the hard disk manufacturers do. In fact I've never seen true throughput numbers from ANY manufacturer. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Kenneth Culver wrote: What I find fascinating is that Maxtor's site never actually tells you the true throughput of that disk anywhere. http://www.maxtor.com/en/products/ata/desktop/diamondmax_plus_9/ Almost none of the hard disk manufacturers do. In fact I've never seen true throughput numbers from ANY manufacturer. Maybe not, but they do give a transferspeed from medium range and that is what can be expected. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Maybe not, but they do give a transferspeed from medium range and that is what can be expected. Hmm, I guess not everyone does that. We have some seagates here at work we were wondering about because they seemed too slow, and we couldn't find anything aside from what we already knew... the tranfer speed of the SCSI interface, which is basically from drive cache to controller. That is unless the manufacturers hide the info somewhere so you really have to dig, which wouldnt' surprise me. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
In the last episode (Jul 31), Kenneth Culver said: What I find fascinating is that Maxtor's site never actually tells you the true throughput of that disk anywhere. http://www.maxtor.com/en/products/ata/desktop/diamondmax_plus_9/ Almost none of the hard disk manufacturers do. In fact I've never seen true throughput numbers from ANY manufacturer. Really? It must be an ATA thing, since I'm not sure I've ever seen a SCSI drive specs page without them (even Maxtor) http://www.maxtor.com/en/products/scsi/atlas_10k_family/atlas_10k_iv/index.htm maximum sustained data transfer rate up to 72MB/sec. http://www.seagate.com/cda/products/discsales/enterprise/family/0,1086,530,00.html Lists not only sustained transfer rate, but tells you the center and edge platter speed range http://ssddom01.hgst.com/tech/techlib.nsf/techdocs/966AE18147C20C8587256BF100656F41/$file/HGSTUltrastar146Z10.PDF Also lists center/edge sustained speeds -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
http://www.maxtor.com/en/products/scsi/atlas_10k_family/atlas_10k_iv/index.htm maximum sustained data transfer rate up to 72MB/sec. http://www.seagate.com/cda/products/discsales/enterprise/family/0,1086,530,00.html Lists not only sustained transfer rate, but tells you the center and edge platter speed range http://ssddom01.hgst.com/tech/techlib.nsf/techdocs/966AE18147C20C8587256BF100656F41/$file/HGSTUltrastar146Z10.PDF Also lists center/edge sustained speeds Guess I just didn't look hard enough or in the right place. I only spent a minute or 2 on it, but yeah ATA drives don't tell you that sort of thing, they say stuff like ATA133 for a max transfer rate of 133 MB/sec * then at the bottom the * says something like 133 MB/sec burst rate from drive to controller or something similar. But I did try fairly hard to find specs on our Seagate drives and couldn't find a hard number that told what the maximum read and write speeds were. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
It seems Kenneth Culver wrote: Guess I just didn't look hard enough or in the right place. I only spent a minute or 2 on it, but yeah ATA drives don't tell you that sort of thing, they say stuff like ATA133 for a max transfer rate of 133 MB/sec * then at the bottom the * says something like 133 MB/sec burst rate from drive to controller or something similar. But I did try fairly hard to find specs on our Seagate drives and couldn't find a hard number that told what the maximum read and write speeds were. Thats maybe true for some drives, but generally they state this info in their docs, for the Diamond 9+ it took me 10 secs to find the below transfer speeds, I did have the PDF handy though :) Disk to Read Once a 236Mb/sec 236Mb/sec236Mb/sec 236Mb/sec Revolutionmminimumminimum minimum minimum 433Mb/sec 433Mb/sec433Mb/sec 433Mb/sec maximummaximum maximum maximum Disk to Read 257Mb/sec 257Mb/sec257Mb/sec 257Mb/sec Instantaneously minimumminimum minimum minimum 472Mb/sec 472Mb/sec472Mb/sec 472Mb/sec maximummaximum maximum maximum -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getfsent(3) and spaces in fstab
Hi, This very discussion came up in -questions a few months ago (or maybe it was late last year). The conclusion was that unless someone rewrites the /etc/fstab parsing routines in libc to support quoted and/or escaped spaces, we'll never be able to mount filesystems that have spaces in their names. I volunteer for that. My intention is to make getfsent(3) recognize '\ ' for both the filesystem and the mount point. I think this is more applicable than using quotes. 'mount' should already handle this correctly, but I will do thorough testing, of course. Cheers, Simon signature.asc Description: Digital signature
vmstat counter bug
Hello, I'm sure this is probably just a limitation of the variable type used, but when we run a 'vmstat -m' on our 4.8-RELEASE machine, we get a negative integer on the Requests section of the memory totals. Memory Totals: In UseFreeRequests 123946K 30979K-1730834065 That negative integer is incrementing towards zero. This is a dual processor machine with 4GB of physical RAM and is running an SMP kernel. This machine pushes about 1TB a month and is used heavily as a web/email/database server, so it naturally puts big numbers through all parts of the OS. Its been running without reboot for 3 months straight now. Is this worth submitting a PR for or is it one of those issues that would sit in the PR db for 7 years because nobody cares? I found the following related PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/30360 open for almost 2 years It's definitely a non-critical issue, but a little spit and polish wouldn't hurt. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Guess I just didn't look hard enough or in the right place. I only spent a minute or 2 on it, but yeah ATA drives don't tell you that sort of thing, they say stuff like ATA133 for a max transfer rate of 133 MB/sec * then at the bottom the * says something like 133 MB/sec burst rate from drive to controller or something similar. But I did try fairly hard to find specs on our Seagate drives and couldn't find a hard number that told what the maximum read and write speeds were. Thats maybe true for some drives, but generally they state this info in their docs, for the Diamond 9+ it took me 10 secs to find the below transfer speeds, I did have the PDF handy though :) Disk to Read Once a 236Mb/sec 236Mb/sec236Mb/sec 236Mb/sec Revolutionmminimumminimum minimum minimum 433Mb/sec 433Mb/sec433Mb/sec 433Mb/sec maximummaximum maximum maximum Disk to Read 257Mb/sec 257Mb/sec257Mb/sec 257Mb/sec Instantaneously minimumminimum minimum minimum 472Mb/sec 472Mb/sec472Mb/sec 472Mb/sec maximummaximum maximum maximum OK you win :-P I just don't know where to look I guess. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Wow. But still, can it be that something bottlenecks somewhere so that I can't get these loverly speeds? Can I measure pci performance as well? Would be cool to understand what doesn't allow this system to use the 133 to its max... Z Guess I just didn't look hard enough or in the right place. I only spent a minute or 2 on it, but yeah ATA drives don't tell you that sort of thing, they say stuff like ATA133 for a max transfer rate of 133 MB/sec * then at the bottom the * says something like 133 MB/sec burst rate from drive to controller or something similar. But I did try fairly hard to find specs on our Seagate drives and couldn't find a hard number that told what the maximum read and write speeds were. Thats maybe true for some drives, but generally they state this info in their docs, for the Diamond 9+ it took me 10 secs to find the below transfer speeds, I did have the PDF handy though :) Disk to Read Once a 236Mb/sec 236Mb/sec236Mb/sec 236Mb/sec Revolutionmminimumminimum minimum minimum 433Mb/sec 433Mb/sec433Mb/sec 433Mb/sec maximummaximum maximum maximum Disk to Read 257Mb/sec 257Mb/sec257Mb/sec 257Mb/sec Instantaneously minimumminimum minimum minimum 472Mb/sec 472Mb/sec472Mb/sec 472Mb/sec maximummaximum maximum maximum KC OK you win :-P I just don't know where to look I guess. KC Ken KC ___ KC [EMAIL PROTECTED] mailing list KC http://lists.freebsd.org/mailman/listinfo/freebsd-hackers KC To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat counter bug
Hi Andrew, On Thu, Jul 31, 2003 at 09:51:32AM -0700, Andrew Kinney wrote: I'm sure this is probably just a limitation of the variable type used, but when we run a 'vmstat -m' on our 4.8-RELEASE machine, we get a negative integer on the Requests section of the memory totals. The field you refer to does not exist under -CURRENT's vmstat(8) command. However, the attached patch should work for you. The bug is caused by a signed integer and printf format being used for the statistic in question, totreq. This is just a running total of what the vmstat(8) command is able to learn from vm_meter.c's exported sysctls. This is a fairly quick patch but you'll need to apply it from within /usr/src/usr.bin/vmstat, then run a make obj/make/make install. I've raised a PR on your behalf with the patch enclosed, it should reach GNATS any second. BMS --- vmstat.c.orig Thu Jul 31 18:26:36 2003 +++ vmstat.cThu Jul 31 18:27:00 2003 @@ -758,7 +758,8 @@ register struct malloc_type *ks; register int i, j; int len, size, first, nkms; - long totuse = 0, totfree = 0, totreq = 0; + long totuse = 0, totfree = 0; + unsigned long totreq = 0; const char *name; struct malloc_type kmemstats[MAX_KMSTATS], *kmsp; char buf[1024]; @@ -862,7 +863,7 @@ totreq += ks-ks_calls; } (void)printf(\nMemory Totals: In UseFreeRequests\n); - (void)printf( %7ldK %6ldK%8ld\n, + (void)printf( %7ldK %6ldK%8lu\n, (totuse + 1023) / 1024, (totfree + 1023) / 1024, totreq); } ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vmstat counter bug
On 31 Jul 2003, at 18:31, Bruce M Simpson wrote: I've raised a PR on your behalf with the patch enclosed, it should reach GNATS any second. Excellent. Thank you! That is more than what I was expecting. Sincerely, Andrew Kinney President and Chief Technology Officer Advantagecom Networks, Inc. http://www.advantagecom.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
isp/ispfw
Hello I am trying to get a Qlogic 2300 to talk to a SAN under 5.1-Release. I have never played with fiber before so I am not sure of what I am supposed to be doing. The device is recognized ok. ahc0: Features 0x1def6, Bugs 0x40, Flags 0x20485540 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs Qlogic ISP Driver, FreeBSD Version 5.9, Core Version 2.7 isp0: Qlogic ISP 2300 PCI FC-AL Adapter port 0x2400-0x24ff mem 0xefffe000-0xef ffefff irq 11 at device 5.0 on pci1 isp0: using I/O space register mapping isp0: Board Type 2300, Chip Revision 0x1, loaded F/W Revision 3.1.20 isp0: Installed in 64-Bit PCI slot isp0: 744 max I/O commands supported isp0: NVRAM Port WWN 0x21e08b05c18e unknown: not probed (disabled) unknown: not probed (disabled) ... ... isp0: LIP Received isp0: Loop UP isp0: Port Database Changed isp0: Firmware State Config Wait-Ready isp0: 2Gb link speed/s isp0: Loop ID 1, AL_PA 0xe8, Port ID 0xe8, Loop State 0x2, Topology 'Private Loo p' isp0: Target 1 (Loop 0x1) Port ID 0xe8 (role Target/Initiator) Arrived Port WWN 0x21e08b05c18e Node WWN 0x20e08b05c18e isp0: Target 0 (Loop 0x0) Port ID 0xef (role Target) Arrived Port WWN 0x50060e80008273d2 Node WWN 0x50060e80008273d2 ata0-master: piomode=12 dmamode=34 udmamode=66 dmaflag=1 ata0-master: success setting PIO4 on ServerWorks ROSB4 chip acd0: LG CD-ROM CRN-8245B/1.13 CDROM drive at ata0 as master ... ... Waiting 15 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. isp0: port unavailable for target 1 isp0: Firmware State Config Wait-Waiting for AL_PA (probe19:isp0:0:4:0): Request Requeued (probe19:isp0:0:4:0): Retrying Command isp0: LIP Received isp0: Firmware State Waiting for AL_PA-Wait Login isp0: Port Database Changed isp0: Firmware State Wait Login-Ready isp0: 2Gb link speed/s isp0: Loop ID 1, AL_PA 0xe8, Port ID 0xe8, Loop State 0x2, Topology 'Private Loo p' isp0: Target 1 (Loop 0x1) Port ID 0xe8 (role Target/Initiator) Arrived Port WWN 0x21e08b05c18e Node WWN 0x20e08b05c18e isp0: Retaining Loop ID 0x0 for Target 0 (Port 0xef) (probe0:ahc0:0:0:0): Retrying Command (ahc0:A:0:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 ... ... start_init: trying /sbin/init Linux ELF exec handler installed isp0: port unavailable for target 1 isp0: Mbox Command Async (0x4000) with no waiters isp0: Firmware State Config Wait-Waiting for AL_PA isp0: LIP Received isp0: Firmware State Waiting for AL_PA-Wait Login isp0: Port Database Changed isp0: Firmware State Wait Login-Ready isp0: 2Gb link speed/s isp0: Loop ID 1, AL_PA 0xe8, Port ID 0xe8, Loop State 0x2, Topology 'Private Loop' isp0: Target 1 (Loop 0x1) Port ID 0xe8 (role Target/Initiator) Arrived Port WWN 0x21e08b05c18e Node WWN 0x20e08b05c18e isp0: Retaining Loop ID 0x0 for Target 0 (Port 0xef) The kernel config is basically GENERIC but has device isp # Qlogic family device ispfw options ISP_TARGET_MODE=1 'camcontrol devlist -v' reports scbus0 on ahc0 bus 0: IBM-PSG DDYS-T18350M M S9HA at scbus0 target 0 lun 0 (pass0,da0) IBM FTlV1 S2 0 at scbus0 target 8 lun 0 (ses0,pass1) at scbus0 target -1 lun -1 () scbus1 on isp0 bus 0: at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: at scbus-1 target -1 lun -1 (xpt0) Using the card bios util, it reports along the lines of: WNN Port 0 Hitachi DF600F 50060E8000827302 EF 1 Qlogic 2300 21E08B05C18E E8 I have booted without defining ISP_TARGET_MODE=1 but the camcntrol devlist -v reports the same. Any ideas on what is wrong (I know nothing about the SAN itself, someone else set it up). thanks -- tonym ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Assembly Syscall Question
When making a system call to the kernel why is it necessary to push the syscall value onto the stack when you don't call another function? Example: access.the.bsd.kernel: int 80h ret func: mov eax, 4; Write call access.the.bsd.kernel ; End Works. However: func: mov eax, 4; Write int 80h ; End Doesn't. Now, if you change it to: func: mov eax, 4; Write push eax int 80h ; End It does work. I was able to find, By default, the FreeBSD kernel uses the C calling convention. Further, although the kernel is accessed using int 80h, it is assumed the program will call a function that issues int 80h, rather than issuing int 80h directly, in the developer's handbook. But I can't figure out why the second example doesn't work. Is the call instruction pushing the value onto the stack in addition to pushing the instruction pointer on? Thank you in advance. PS I'm not on the list. -- Ryan leadZERO Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Issues with large drives going back to PIO
Hello. A few months ago (May) to be exact, Søren posted a patch ( http://lists.freebsd.org/pipermail/freebsd-current/2003-May/003275.html ) to the FreeBSD-current mailing list relating to IDE drives over a certian size having issues with falling back to PIO mode and other things. This patch was commited, and is currently in 5.1-RELEASE, and my friend told me to try applying to the patch to fix the problem (although the patch was already commited). There does NOT appear to be anything wrong with the drives, as I have run tests on them and stuck them in another FreeBSD 5.1-RELEASE box, and the problem seems to disappear. The error I'm getting is..: Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198898911 of 198898911-198899166 retrying Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 retrying Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 retrying Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 retrying Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 falling back to PIO mode and ad3: UDMA ICRC error cmd=write fsbn 198898911 of 198898911-198899166 retrying ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 retrying ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 retrying ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 retrying ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 retrying ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 retrying ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 falling back to PIO mode The drives are 120GB Maxtor 7200RPM with 2MB cache, I have 3 of them; and I have experienced the same error with FreeBSD 5.1-RELEASE, and 4.8-RELEASE (4.8, which always made the drives go back to PIO mode no matter what). The board is a Asus P4SDX: ad0: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata0-master UDMA133 ad1: 78167MB Maxtor 4R080J0 [158816/16/63] at ata0-slave UDMA133 ad2: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-master UDMA133 ad3: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-slave UDMA133 uname -a output: FreeBSD devil.mphknet.ca 5.1-RELEASE FreeBSD 5.1-RELEASE #0: Sun Jul 6 14:15:37 PDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/DEVIL i386 dmesg: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #0: Sun Jul 6 14:15:37 PDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/DEVIL Preloaded elf kernel /boot/kernel/kernel at 0xc0442000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0442244. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1600119912 Hz CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz (1600.12-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536854528 (511 MB) avail memory = 516734976 (492 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P4SDXon motherboard pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f1630 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 atapci0: SiS 963 UDMA133 controller port 0xb400-0xb40f,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 irq 11 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, USB at device 3.0 (no driver attached) pci0: serial bus, USB at device 3.1 (no driver attached) pci0: serial bus, USB at device 3.3 (no driver attached) sis0: SiS 900 10/100BaseTX port 0x9800-0x98ff mem 0xf600-0xf6000fff at device 4.0 on pci0 pcib0: slot 4 INTA is routed to irq 5 sis0: Ethernet address: 00:0c:6e:2b:46:ed miibus0: MII bus on sis0 rlphy0: RTL8201L 10/100 media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: display, VGA at device 9.0 (no driver attached) fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset
Re: Console serial speed
Russell Cattelan writes: | On Wed, 2003-07-30 at 21:58, Doug Ambrisko wrote: | Russell Cattelan writes: | | How does one set the serial speed of the console. | | I changed the boot loader speed to 57600 in make.conf | | but the kernel seems to chose random speeds each time | | it's booted. | | Sometimes it's 9600 sometimes it 115200 other times | | it's 38400. | | | | Note this is on 5.x current | | You might want to check sys/isa/sio.c in function siocngetspeed. | I comment out the return (rclk / (16UL * divisor)); on some of my | stable boxes. I've seen a few motherboards that result in a messed | up console if I don't do it (ie. wrong speed). | | I changed the return val to be CONSPEED. | The machine now boots with the console speed correctly set | to 57600 | | Thanks... suppose a proper fix would be good :-) I'm not sure what a proper fix would be. We try to read the speed out of the UART and it fails to get what it was set to. This could be broken hardware etc. Personally I haven't had the motivation to figure out why some machines fail and I just wacked the code to make it work so I can actually fix the real problem I was working on! Maybe some #define that could over-ride everything and just set might be a fix for broken HW. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isp/ispfw
On Sun, Jul 20, 2003 at 08:34:55PM +1000, Tony Maher wrote: ... isp0: 2Gb link speed/s isp0: Loop ID 1, AL_PA 0xe8, Port ID 0xe8, Loop State 0x2, Topology 'Private Loop' isp0: Target 1 (Loop 0x1) Port ID 0xe8 (role Target/Initiator) Arrived Port WWN 0x21e08b05c18e Node WWN 0x20e08b05c18e isp0: Target 0 (Loop 0x0) Port ID 0xef (role Target) Arrived Port WWN 0x50060e80008273d2 Node WWN 0x50060e80008273d2 The WWN for #1 is the ISP while #0 (AL_PA 0xef) is an array maybe. 'camcontrol devlist -v' reports scbus0 on ahc0 bus 0: IBM-PSG DDYS-T18350M M S9HA at scbus0 target 0 lun 0 (pass0,da0) IBM FTlV1 S2 0 at scbus0 target 8 lun 0 (ses0,pass1) at scbus0 target -1 lun -1 () scbus1 on isp0 bus 0: at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: What does 'camcontrol rescan 1:0:0' report? -- Chuck Tufflichuck_tuffli AT NO_SPAM agilent DOT com Agilent Technologies, Storage and Networking ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issues with large drives going back to PIO
Woo. I have just the same thing with a 10Gb Seagate Barracuda ATA III drive here. It appears to occur only when Seagate is attached to the wonderful SI0680 controller (falls back to PIO during boot time and after resetting through atacontrol). There's definitely a 'thing' about these controllers. It never does happen on WDMA modes though, on internal Intel controller. But I have an idea - this Seagate drive has some bad sectors in there, so I had Windows sometimes falling back to PIO for this drive because of these physical errors. Strange anyway. And we seem to have one thing in common: dual PentiumPro systems... Z PK Hello. PK A few months ago (May) to be exact, Søren posted a patch ( PK http://lists.freebsd.org/pipermail/freebsd-current/2003-May/003275.html PK ) to the FreeBSD-current mailing list relating to IDE drives over a certian PK size having issues with falling back to PIO mode and other things. This PK patch was commited, and is currently in 5.1-RELEASE, and my friend told me PK to try applying to the patch to fix the problem (although the patch was PK already commited). There does NOT appear to be anything wrong with the PK drives, as I have run tests on them and stuck them in another FreeBSD PK 5.1-RELEASE box, and the problem seems to disappear. PK The error I'm getting is..: PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198898911 PK of 198898911-198899166 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198902239 PK of 198902239-198902494 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn 198902239 PK of 198902239-198902494 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn 203789023 PK of 203789023-203789038 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn 203789023 PK of 203789023-203789038 falling back to PIO mode PK and PK ad3: UDMA ICRC error cmd=write fsbn 198898911 of 198898911-198899166 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 falling PK back to PIO mode PK The drives are 120GB Maxtor 7200RPM with 2MB cache, I have 3 of them; and I PK have experienced the same error with FreeBSD 5.1-RELEASE, and 4.8-RELEASE PK (4.8, which always made the drives go back to PIO mode no matter what). The PK board is a Asus P4SDX: PK ad0: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata0-master UDMA133 PK ad1: 78167MB Maxtor 4R080J0 [158816/16/63] at ata0-slave UDMA133 PK ad2: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-master UDMA133 PK ad3: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-slave UDMA133 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
When making a system call to the kernel why is it necessary to push the syscall value onto the stack when you don't call another function? You have to push anything the size of an address. Because the call return pushes the return adress on the stack. The 1st and 3rd both push 4 bytes, so they work. _why_ this is needed is probably because the routine that does the int 80h can also check and process the int 80h returnvalue and errorcode, and people wanted to avoid duplication of that code, at least that is my guess :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issues with large drives going back to PIO
Haha, laugh! I bought it 2 years ago, this was the dream of my childhood, in 1996 I was literally drooling over anything PentiumPro and dual seemed like an impossible dream. Was VERY hard to find, the motherboard especially. Bought from some guy who kept them in a garage. Cost $30 + $10(!) for a PPro radiator. It would still be more than satisfactory if only it wasn't the need to write large amount of CDs at 48x speed and that's why I'd need UDMA controller. The rest is recorded history. But Gigabyte sucks anyway. I've yet to see a BIOS THIS buggy (as in my current PPro motherboard). Z PS. Do you want to buy one? It's packed in a lovely Thermaltake Xaser II case by the way, lighting included! Friday, August 1, 2003, 2:35:19 AM, you wrote: PK Where are you getting Dual PentiumPro system from?? PK --Peter PK - Original Message - PK From: Buckie [EMAIL PROTECTED] PK To: [EMAIL PROTECTED] PK Sent: Thursday, July 31, 2003 3:14 PM PK Subject: Re: Issues with large drives going back to PIO PK Woo. I have just the same thing with a 10Gb Seagate Barracuda ATA III PK drive here. It appears to occur only when Seagate is attached to the PK wonderful SI0680 controller (falls back to PIO during boot time and PK after resetting through atacontrol). There's definitely a 'thing' PK about these controllers. It never does happen on WDMA modes though, on PK internal Intel controller. PK But I have an idea - this Seagate drive has some bad sectors in there, PK so I had Windows sometimes falling back to PIO for this drive because PK of these physical errors. Strange anyway. PK And we seem to have one thing in common: dual PentiumPro systems... PK Z PK Hello. PK A few months ago (May) to be exact, Søren posted a patch ( PK http://lists.freebsd.org/pipermail/freebsd-current/2003-May/003275.html PK ) to the FreeBSD-current mailing list relating to IDE drives over a PK certian PK size having issues with falling back to PIO mode and other things. This PK patch was commited, and is currently in 5.1-RELEASE, and my friend told PK me PK to try applying to the patch to fix the problem (although the patch was PK already commited). There does NOT appear to be anything wrong with the PK drives, as I have run tests on them and stuck them in another FreeBSD PK 5.1-RELEASE box, and the problem seems to disappear. PK The error I'm getting is..: PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn PK 198898911 PK of 198898911-198899166 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn PK 198902239 PK of 198902239-198902494 retrying PK Jul 26 18:17:58 devil kernel: ad3: UDMA ICRC error cmd=write fsbn PK 198902239 PK of 198902239-198902494 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn PK 203789023 PK of 203789023-203789038 retrying PK Jul 29 12:43:28 devil kernel: ad2: UDMA ICRC error cmd=write fsbn PK 203789023 PK of 203789023-203789038 falling back to PIO mode PK and PK ad3: UDMA ICRC error cmd=write fsbn 198898911 of 198898911-198899166 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad3: UDMA ICRC error cmd=write fsbn 198902239 of 198902239-198902494 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK retrying PK ad2: UDMA ICRC error cmd=write fsbn 203789023 of 203789023-203789038 PK falling PK back to PIO mode PK The drives are 120GB Maxtor 7200RPM with 2MB cache, I have 3 of them; PK and I PK have experienced the same error with FreeBSD 5.1-RELEASE, and PK 4.8-RELEASE PK (4.8, which always made the drives go back to PIO mode no matter what). PK The PK board is a Asus P4SDX: PK ad0: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata0-master UDMA133 PK ad1: 78167MB Maxtor 4R080J0 [158816/16/63] at ata0-slave UDMA133 PK ad2: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-master UDMA133 PK ad3: 117246MB Maxtor 6Y120L0 [238216/16/63] at ata1-slave UDMA133 PK ___ PK [EMAIL PROTECTED] mailing list PK http://lists.freebsd.org/mailman/listinfo/freebsd-hackers PK To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best regards, Buckiemailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getfsent(3) and spaces in fstab
For all the 'good rules' of orthonogolity and consistency etc it is a good thing, however I still feel that at the level of the fstab where you are mounting entire file system trees, the simplest naming formats are probably the best. A philosophical point only, but it would keep the fstab format minimalistic and clean. This point of view could probably be stated in the man page once the '\ ' form is implemented, as a suggested practice. another 0.02c mjt On Thu, 2003-07-31 at 13:43, Simon Barner wrote: Hi, This very discussion came up in -questions a few months ago (or maybe it was late last year). The conclusion was that unless someone rewrites the /etc/fstab parsing routines in libc to support quoted and/or escaped spaces, we'll never be able to mount filesystems that have spaces in their names. I volunteer for that. My intention is to make getfsent(3) recognize '\ ' for both the filesystem and the mount point. I think this is more applicable than using quotes. 'mount' should already handle this correctly, but I will do thorough testing, of course. Cheers, Simon This Email has been scanned for Viruses by MailMarshal. -- Murray Taylor Special Projects Engineer - Bytecraft Systems Entertainment P: +61 3 8710 2555 F: +61 3 8710 2599 D: +61 3 9238 4275 M: +61 417 319 256 E: [EMAIL PROTECTED] or visit us on the web http://www.bytecraftsystems.com http://www.bytecraftentertainment.com This Email has been scanned for Viruses by MailMarshal. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Maybe not, but they do give a transferspeed from medium range and that is what can be expected. Hmm, I guess not everyone does that. We have some seagates here at work we were wondering about because they seemed too slow, and we couldn't find anything aside from what we already knew... the tranfer speed of the SCSI interface, which is basically from drive cache to controller. That is unless the manufacturers hide the info somewhere so you really have to dig, which wouldnt' surprise me. Example took me less than 64 seconds to find (for Seagate Barracuda IV): http://www.seagate.com/cda/products/discsales/personal/family/0,1085,559,00.html Look for 'Avg. Sustained Transfer Rate'. AFAIK, every manufacturer I know gives the sustained transfer rate specs (which are sometime a bit too high than in reality). If the specs are not specified, it'd be very suspicious, and I would think 128 time before buying such drives. 31.07.2003; 18:28:06 [SorAlx] http://cydem.org.ua/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getfsent(3) and spaces in fstab
On Thu, 31 Jul 2003, Simon Barner wrote: Just a thort, not having tried it .. does either of the 'standard' methods of including spaces actually work in fstab ?? I speak of quoting (either single or double) and backslashing the space /mnt/space/silly long dirname/filename also with spaces or /mnt/space/silly\ long\ dirname/filename\ also\ with\ spaces Sorry, I should have written that I have performed tests: Here is what I did: test\ 1 /mnt/test\ 1ufs ro 0 0 'test 2''/mnt/test 2' ufs ro 0 0 test 3/mnt/test 3 ufs ro 0 0 This test program [...snipped...] Gives me the following output: fstab: /etc/fstab:14: Inappropriate file type or format fstab: /etc/fstab:15: Inappropriate file type or format fstab: /etc/fstab:16: Inappropriate file type or format What about test%201/mnt/test%201 ufs ro 0 0 ? Ugly, yes, but that's how a lot of tools escape spaces. -- Chris BeHanna Software Engineer (Remove bogus before responding.) [EMAIL PROTECTED] Turning coffee into software since 1990. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
Soeren Schmidt wrote: It seems Buckie wrote: I ran a dd: dd if=/dev/ad1 of=/dev/zero ibs=8192 OH, you need to output to /dev/null NOT /dev/zero :) It doesn't matter as far as cdevsw entry for zero-device write leads to null_write() in /usr/src/sys/dev/null.c I was testing the memory to memory copy through a driver using /dev/null and /dev/zero and with dd if=/dev/zero of=/dev/null I get till 4.2Gb/s. Is it a maximum for memory throughout + cpu work ? (2.4GHz Laptop with SDRAM) Varying the bs parameter from 512 to 65536, I get a linear progression until bs=65536 (previous throughout) but the relative throughout is lower for bs=1024. Someone could explain? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Support for MegaRaid SATA 150-6 ?
I got some hardware in today, which unfortunatly is going to be used for RedStain, but I got time over the weekend to play with it and I wanna put some FreeBSD on it. The controller is a LSI Logic MegaRaid SATA 150-6 (6 channel). Any of the 5.1-REL drivers support that ? The motherboard is a Supermicro with E7501 chipset and two intel 82541 GigE controllers. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://seven.Alameda.net/~ulf/resume.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getfsent(3) and spaces in fstab
At 10:16 PM -0400 7/31/03, Chris BeHanna wrote: Sorry, I should have written that I have performed tests: Here is what I did: test\ 1 /mnt/test\ 1ufs ro 0 0 'test 2''/mnt/test 2' ufs ro 0 0 test 3/mnt/test 3 ufs ro 0 0 [...etc...] What about test%201/mnt/test%201 ufs ro 0 0 ? Ugly, yes, but that's how a lot of tools escape spaces. There may be people who already mount directories with %'s in them. If you wanted to be fancy, there could be some kind of trigger that says after this point, recognize URL-style escaping rules. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: getfsent(3) and spaces in fstab
On Thu, 31 Jul 2003, Chris BeHanna wrote: What about test%201/mnt/test%201 ufs ro 0 0 ? Ugly, yes, but that's how a lot of tools escape spaces. Just FYI, here is how Linux handles this (from fstab(5)): The second field, (fs_file), describes the mount point for the filesys- tem. For swap partitions, this field should be specified as `none'. If the name of the mount point contains spaces these can be escaped as `\040'. It might be a good idea to use this method rather than inventing a new one. -- Tod McQuillin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ultra ATA card doesn't seem to provide Ultra speeds.
On Thu, Jul 31, 2003 at 06:33:28PM -0600, [EMAIL PROTECTED] wrote: Maybe not, but they do give a transferspeed from medium range and that is what can be expected. Hmm, I guess not everyone does that. We have some seagates here at work we were wondering about because they seemed too slow, and we couldn't find anything aside from what we already knew... the tranfer speed of the SCSI interface, which is basically from drive cache to controller. That is unless the manufacturers hide the info somewhere so you really have to dig, which wouldnt' surprise me. Example took me less than 64 seconds to find (for Seagate Barracuda IV): http://www.seagate.com/cda/products/discsales/personal/family/0,1085,559,00.html Look for 'Avg. Sustained Transfer Rate'. AFAIK, every manufacturer I know gives the sustained transfer rate specs (which are sometime a bit too high than in reality). If the specs are not specified, it'd be very suspicious, and I would think 128 time before buying such drives. The transfer rates are usually given for the outside of the disk I think. Speeds usually drop about 15-20MB/s between the outside and inside. If you've got FreeBSD 5.1, you can use the 'diskinfo -t disk' command to measure the performance of the hard drive. It should be a little more accurate than using dd, because I'm guessing the reads/writes don't go through the vfs layer. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Console serial speed
On Wed, 2003-07-30 at 21:58, Doug Ambrisko wrote: Russell Cattelan writes: | How does one set the serial speed of the console. | I changed the boot loader speed to 57600 in make.conf | but the kernel seems to chose random speeds each time | it's booted. | Sometimes it's 9600 sometimes it 115200 other times | it's 38400. | | Note this is on 5.x current You might want to check sys/isa/sio.c in function siocngetspeed. I comment out the return (rclk / (16UL * divisor)); on some of my stable boxes. I've seen a few motherboards that result in a messed up console if I don't do it (ie. wrong speed). I changed the return val to be CONSPEED. The machine now boots with the console speed correctly set to 57600 Thanks... suppose a proper fix would be good :-) Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Assembly Syscall Question
On Thu, Jul 31, 2003 at 04:12:27PM -0400, Ryan Sommers wrote: When making a system call to the kernel why is it necessary to push the syscall value onto the stack when you don't call another function? Example: access.the.bsd.kernel: int 80h ret func: mov eax, 4; Write call access.the.bsd.kernel ; End Works. However: func: mov eax, 4; Write int 80h ; End Doesn't. This is because in a C library, all system calls are wrapped into C functions, so the stack looks like this when in the syscall code in libc: return address to a program syscall args So the kernel knows how to account for a return address to access actual arguments. So when calling the kernel directly (not through a C library wrapper function), we need to align the stack to fake the kernel we're calling it from the syscall code in libc. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Netgraph node, first steps in kernel land and a bloody crash dump
Hi guys,
still here with my netgraph node.
Today, after a couple of nice days without a problem,
i spent the last 4 hours trying to understand why the hell,
my module crash my stable box.
DISCLAIMER: this is my first real attempt to work
in kernel land, so it's quite possibile that i did
something so stupid to not recognize it... =P
anyway, this is a crash dump:
(kgdb) exec-file /var/crash/kernel.0
(kgdb) core-file /var/crash/vmcore.0
IdlePTD at phsyical address 0x0033c000
initial pcb at physical address 0x0026bb20
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x310
fault code = supervisor read, page not present
instruction pointer = 0x8:0x310
stack pointer = 0x10:0xccf7ece4
frame pointer = 0x10:0xccf7ecf0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 620 (thesis)
interrupt mask =
trap number = 12
panic: page fault
syncing disks... 13 1
done
Uptime: 13m29s
dumping to dev #ad/0x20001, offset 230752
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109
108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85
84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 5
8 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3
2 1
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc0157b9f in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2 0xc0157fc4 in poweroff_wait (junk=0xc023f64c, howto=-1071386289)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc02056a6 in trap_fatal (frame=0xccf7eca4, eva=784)
at /usr/src/sys/i386/i386/trap.c:974
#4 0xc0205379 in trap_pfault (frame=0xccf7eca4, usermode=0, eva=784)
at /usr/src/sys/i386/i386/trap.c:867
#5 0xc0204f63 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -856166976, tf_esi = 0, tf_ebp = -856167184,
tf_isp = -856167216, tf_ebx = 69, tf_edx = 0, tf_ecx = 0,
tf_eax = -6422529, tf_trapno = 12, tf_err = 0, tf_eip = 784, tf_cs = 8,
tf_eflags = 66118, tf_esp = -1071208512, tf_ss = 1861})
at /usr/src/sys/i386/i386/trap.c:466
#6 0x310 in ?? ()
#7 0xc0163e70 in putchar (c=69, arg=0xccf7edc0)
at /usr/src/sys/kern/subr_prf.c:355
#8 0xc0164086 in kvprintf (fmt=0xc0e24baa AF NODE\n,
func=0xc0163dd0 putchar, arg=0xccf7edc0, radix=10, ap=0xccf7edd8 )
at /usr/src/sys/kern/subr_prf.c:532
#9 0xc0163d4c in printf (fmt=0xc0e24ba8 LEAF NODE\n)
at /usr/src/sys/kern/subr_prf.c:305
#10 0xc0e2348a in ?? ()
#11 0xc0e23354 in ?? ()
#12 0xc019bc15 in ng_send_data (hook=0xc0cf4a40, m=0xc0748d00, meta=0x0)
at /usr/src/sys/netgraph/ng_base.c:1649
#13 0xc0de12be in ?? ()
#14 0xc01769e3 in sosend (so=0xcc6e0580, addr=0xc0bc44c0, uio=0xccf80ed8,
top=0xc0748d00, control=0x0, flags=0, p=0xc7bd9080)
at /usr/src/sys/kern/uipc_socket.c:609
#15 0xc0179e27 in sendit (p=0xc7bd9080, s=4, mp=0xccf80f18, flags=0)
at /usr/src/sys/kern/uipc_syscalls.c:590
#16 0xc0179ee6 in sendto (p=0xc7bd9080, uap=0xccf80f80)
at /usr/src/sys/kern/uipc_syscalls.c:643
#17 0xc02058ca in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077937886, tf_esi = 671679608, tf_ebp = -1077937864,
tf_isp = -856158252, tf_ebx = 671679968, tf_edx = 134565966,
tf_ecx = -9, tf_eax = 133, tf_trapno = 0, tf_err = 2,
tf_eip = 671912972, tf_cs = 31, tf_eflags = 643, tf_esp = -1077937956,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175
#18 0xc01f9615 in Xint0x80_syscall ()
#19 0x80522c4 in ?? ()
#20 0x80523b0 in ?? ()
#22 0x805251a in ?? ()
#23 0x805251a in ?? ()
#24 0x805251a in ?? ()
#25 0x805251a in ?? ()
#26 0x80495ce in ?? ()
#27 0x8048ada in ?? ()
Ok, i'm not a guru, but it looks like the culprit is printf in kernel
land, or at least, a bad use of it from myself... (see #9).
I would like to fill the missing ?? in this dump, but i couldn't
find how to load the symbols from my node (and yes, i've
tried what's written in the handbook about the modules and
it didn't work).
Ok, enough for today, i wish someone could shed some
light here, cause i really gave up... =(
on a side note:
[EMAIL PROTECTED] flag]$ man 9 printf
No entry for printf in section 9 of the manual
[EMAIL PROTECTED] flag]$
what's happened to the man page?
thank you.
--
Paolo
GUFI: http://www.gufi.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
wi0 still not being a good hostap.
Well... I was wrong. Interrups under 5.1-CURRENT still cause the wi0 running in hostap mode to shed it's clients. I'm not familiar with what 802.11b does to authenticate et. al., so I'm posting this ifconfig debug output from both the server and the client in hopes someone else knows what's happening. This particular system has two clients. It's worth noting that when I had a normal access point, I had no problems. This appears to be a problem with the wi0 in hostap mode. The server says: wi0: sending assoc_resp to 00:40:05:ae:b1:bf on channel 11 wi0: station newly 00:40:05:ae:b1:bf associated wi0: received disassoc from 00:40:05:ae:b1:bf rssi 42 wi0: station 00:40:05:ae:b1:bf disassociated by peer (reason 8) wi0: received auth from 00:40:05:ae:b1:bf rssi 41 wi0: sending auth to 00:40:05:ae:b1:bf on channel 11 wi0: station already 00:40:05:ae:b1:bf authenticated wi0: received assoc_req from 00:40:05:ae:b1:bf rssi 39 wi0: received auth from 00:40:05:ae:b1:bf rssi 42 wi0: sending auth to 00:40:05:ae:b1:bf on channel 11 wi0: station already 00:40:05:ae:b1:bf authenticated wi0: received assoc_req from 00:40:05:ae:b1:bf rssi 42 wi0: sending assoc_resp to 00:40:05:ae:b1:bf on channel 11 wi0: station newly 00:40:05:ae:b1:bf associated wi0: station 05:ae:05:ae:b1:bf deauthenticate (reason 6) wi0: sending deauth to 05:ae:05:ae:b1:bf on channel 11 wi0: received auth from 00:04:e2:1e:11:d7 rssi 35 wi0: sending auth to 00:04:e2:1e:11:d7 on channel 11 wi0: station already 00:04:e2:1e:11:d7 authenticated wi0: received assoc_req from 00:04:e2:1e:11:d7 rssi 33 wi0: sending assoc_resp to 00:04:e2:1e:11:d7 on channel 11 wi0: station already 00:04:e2:1e:11:d7 associated wi0: received auth from 00:40:05:ae:b1:bf rssi 40 wi0: sending auth to 00:40:05:ae:b1:bf on channel 11 wi0: station already 00:40:05:ae:b1:bf authenticated wi0: received deauth from 00:40:05:ae:b1:bf rssi 40 wi0: station 00:40:05:ae:b1:bf deauthenticated by peer (reason 3) wi0: received assoc_req from 00:40:05:ae:b1:bf rssi 38 wi0: station 00:40:05:ae:b1:bf deauthenticate (reason 9) wi0: sending deauth to 00:40:05:ae:b1:bf on channel 11 wi0: received auth from 00:40:05:ae:b1:bf rssi 37 wi0: sending auth to 00:40:05:ae:b1:bf on channel 11 wi0: station newly 00:40:05:ae:b1:bf authenticated wi0: received assoc_req from 00:40:05:ae:b1:bf rssi 40 wi0: sending assoc_resp to 00:40:05:ae:b1:bf on channel 11 wi0: station newly 00:40:05:ae:b1:bf associated wi0: station 00:40:05:ae:00:05 deauthenticate (reason 6) wi0: sending deauth to 00:40:05:ae:00:05 on channel 11 wi0: receive packet with wrong version: d5 wi0: receive packet with wrong version: d5 The client says (not nearly so long a sample): wi0: D Link DWL-650 11Mbps WLAN Card at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:40:05:ae:b1:bf wi0: using RF:PRISM2.5 MAC:ISL3873 wi0: Intersil Firmware: Primary (1.0.7), Station (1.3.5) wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wi0: station 00:05:5d:ee:e6:e7 disassociate (reason 8) wi0: sending disassoc to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 deauthenticate (reason 3) wi0: sending deauth to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 disassociate (reason 8) wi0: sending disassoc to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 deauthenticate (reason 3) wi0: sending deauth to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 disassociate (reason 8) wi0: sending disassoc to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 deauthenticate (reason 3) wi0: sending deauth to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 disassociate (reason 8) wi0: sending disassoc to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 deauthenticate (reason 3) wi0: sending deauth to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 disassociate (reason 8) wi0: sending disassoc to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 deauthenticate (reason 3) wi0: sending deauth to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 disassociate (reason 8) wi0: sending disassoc to 00:05:5d:ee:e6:e7 on channel 11 wi0: station 00:05:5d:ee:e6:e7 deauthenticate (reason 3) wi0: sending deauth to 00:05:5d:ee:e6:e7 on channel 11 Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
