Re: Monitoring temperature with acpi (sysctls)
Jiawei Ye wrote: On 7/27/06, Mike Jakubik [EMAIL PROTECTED] wrote: I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. What about using SMBus? Is it available on your system? xmbmon reads temperatures off the SMBus IIRC. I tried that, unfortunately it does not work. All i want to know is if this a shortcoming of freebsd or the motherboard, if its the later, i will contact the manufacturer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
On Wed, 26 Jul 2006 13:07:19 -0400 Sven Willenberger [EMAIL PROTECTED] wrote: Feargal Reilly presumably uttered the following on 07/24/06 11:48: Looking again at dumpfs, it appears to say that this is formatted with a block size of 8K, and a fragment size of 2K, but tuning(7) says: [...] Reading this makes me think that when this server was installed, the block size was dropped from the 16K default to 8K for performance reasons, but the fragment size was not modified accordingly. Would this be the root of my problem? I think a bsize/fsize ratio of 4/1 _should_ work, but it's not widely used, so there might be bugs hidden somewhere. Such as df not reporting the actual data usage, which is now my best working theory. I don't know what df bases it's figures on, perhaps it either slowly got out of sync, or more likely, got things wrong once the disk filled up. One of my machines that I recently upgraded to 6.1 (6.1-RELEASE-p3) is also exhibiting df reporting wrong data usage numbers. Notice the negative Used numbers below: df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M 63M393M14%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e989M -132M1.0G -14%/tmp /dev/da0s1f 15G478M 14G 3%/usr /dev/da0s1d 15G -1.0G 14G-8%/var /dev/md0 496M228K456M 0%/var/spool/MIMEDefang devfs 1.0K1.0K 0B 100%/var/named/dev Sven For the record, my problems occured with 5.4-PRERELEASE #1 which, for reasons beyond my control, I had not yet been unable to upgrade. What bsize/fsize ratio are you using? Mine was 4/1 instead of the more usual 8/1. BTW, anybody know what the best method be for double-checking df's figures would be? du? -- Feargal Reilly. PGP Key: 0x847DE4C8 (expires: 2006-11-30) Web: http://www.helgrim.com/ | ICQ: 109837009 | YIM: ectoraige Visit http://ie.bsd.net/ - BSDs presence in Ireland signature.asc Description: PGP signature
Re: Monitoring temperature with acpi (sysctls)
On Thu, Jul 27, 2006 at 02:25:19AM -0400, Mike Jakubik wrote: Jiawei Ye wrote: On 7/27/06, Mike Jakubik [EMAIL PROTECTED] wrote: I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. What about using SMBus? Is it available on your system? xmbmon reads temperatures off the SMBus IIRC. I tried that, unfortunately it does not work. All i want to know is if this a shortcoming of freebsd or the motherboard, if its the later, i will contact the manufacturer. Could you please try (if you have a working smb device) # smbmsg -p -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Wed, Jul 26, 2006 at 02:52:53PM -0400, Mike Jakubik wrote: David Duchscher wrote: On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: Does this one support IPMI? Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can confirm that it works with the IPMI ported driver from current on 6.1. The module is optional so you will have to purchase one for the system, around 0. You will also need the latest BIOS loaded on the motherboard for it to work. http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. Have you tried ports/sysutils/mbmon? It can try to get the values in different ways, e.g. accessing the chip directly, smbus or isa. It is easily scriptable. I use it in combination with gnuplot in a shell-script to make a graph of the CPU and motherboard temperatures; http://www.xs4all.nl/~rsmith/freebsd/index.html#monitor Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpZq4RCMHy7l.pgp Description: PGP signature
SW_WATCHDOG panic
While trying to debug why I couldn't use powerd(8) with two batteries in my IBM T41 (which seems related to kern/97383), I turned on SW_WATCHDOG only to get an almost immediate panic after turning it on with watchdog(8). Sources are from July 10 RELENG_6. Backtrace http://people.freebsd.org/~erwin/rabbit.txt If anyone wants to have a look, let me know if you need more information. Cheers, -erwin -- Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_///[EMAIL PROTECTED] And it makes you cry.) ([EMAIL PROTECTED] pgpqlYd0kxcw4.pgp Description: PGP signature
Re: Monitoring temperature with acpi (sysctls)
Jiawei Ye wrote: On 7/27/06, Mike Jakubik [EMAIL PROTECTED] wrote: I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. What about using SMBus? Is it available on your system? xmbmon reads temperatures off the SMBus IIRC. Jiawei Ye But also not working on ASUS A8N32-SLI Deluxe or at my lab's ASUS P800! On ASUS A8N-SLI Deluxe xmbmon worked fine! SMBus never worked on any ASUS, don't know why. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
Roland Smith wrote: On Wed, Jul 26, 2006 at 02:52:53PM -0400, Mike Jakubik wrote: David Duchscher wrote: On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: Does this one support IPMI? Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can confirm that it works with the IPMI ported driver from current on 6.1. The module is optional so you will have to purchase one for the system, around 0. You will also need the latest BIOS loaded on the motherboard for it to work. http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. Have you tried ports/sysutils/mbmon? It can try to get the values in different ways, e.g. accessing the chip directly, smbus or isa. It is easily scriptable. I use it in combination with gnuplot in a shell-script to make a graph of the CPU and motherboard temperatures; http://www.xs4all.nl/~rsmith/freebsd/index.html#monitor Roland I did and it only worked for my on an ASUS A8N-SLI Deluxe. ASUS A8N32-SLI Deluxe evidently uses another IO chip (or e newer revision) and on my lab's i386 ASUS P800 system I have the same problem, neither ACPI, smbus nor anything else seems to work or obtain temperature/fan speed. It's funny, on those boxes xmbmon/mbmon worked fine I also saw ACPI thermal zones and fan speed (expecially my older ASUS A8N-SLI Deluxe). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Thu, Jul 27, 2006 at 03:31:56PM +0200, O. Hartmann wrote: Roland Smith wrote: On Wed, Jul 26, 2006 at 02:52:53PM -0400, Mike Jakubik wrote: David Duchscher wrote: On Jul 26, 2006, at 11:09 AM, Bruno Ducrot wrote: Does this one support IPMI? Yes, the Supermicro PDSMi supports the IPMI 2.0 module and I can confirm that it works with the IPMI ported driver from current on 6.1. The module is optional so you will have to purchase one for the system, around 0. You will also need the latest BIOS loaded on the motherboard for it to work. http://www.supermicro.com/products/accessories/addon/AOC-IPMI20-E.cfm I don't want to spend $50 extra per system, just so i can read the temperature, and not even use any of the IPMI functions. I need a simple and scriptable way to get the values, acpi sysctls are ideal for this. Have you tried ports/sysutils/mbmon? It can try to get the values in different ways, e.g. accessing the chip directly, smbus or isa. It is easily scriptable. I use it in combination with gnuplot in a shell-script to make a graph of the CPU and motherboard temperatures; http://www.xs4all.nl/~rsmith/freebsd/index.html#monitor Roland I did and it only worked for my on an ASUS A8N-SLI Deluxe. ASUS A8N32-SLI Deluxe evidently uses another IO chip (or e newer revision) and on my lab's i386 ASUS P800 system I have the same problem, neither ACPI, smbus nor anything else seems to work or obtain temperature/fan speed. It's funny, on those boxes xmbmon/mbmon worked fine I also saw ACPI thermal zones and fan speed (expecially my older ASUS A8N-SLI Deluxe). My ASUS K8V DeLuxe doesn't work with ACPI; there is no hw.acpi.thermal sysctl. The only thing that seems to work is mbmon via the ISA interface. Trying SMBus gives nonsense values. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpxSTzA0fFyl.pgp Description: PGP signature
Gigabyte K8-NF-9 and SMBus
Hello, Following an interesting discussion about temperature monitoring on this mailing list, I decided to try this on a machine with the Gigabyte K8-NF-9 motherboard (the only machine which I can get a /dev/smb0 device on). It runs 6.1-stable: [EMAIL PROTECTED] uname -a FreeBSD kg-fil.kg4.no 6.1-STABLE FreeBSD 6.1-STABLE #8: Sun May 7 22:51:56 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FIL60 amd64 I load the following modules: [EMAIL PROTECTED] kldload ichsmb [EMAIL PROTECTED] kldload smb which gives this output in /var/log/messages: Jul 27 16:31:58 kg-fil kernel: ichsmb0: SMBus controller port 0xe800-0xe81f,0x 1c00-0x1c3f,0x1c40-0x1c7f irq 20 at device 1.1 on pci0 Jul 27 16:31:58 kg-fil kernel: ichsmb0: [GIANT-LOCKED] Jul 27 16:31:58 kg-fil kernel: smbus0: System Management Bus on ichsmb0 Jul 27 16:32:16 kg-fil kernel: smb0: SMBus generic I/O on smbus0 But when I try 'smbmsg -p' I get this in /var/log/messages: Jul 27 16:32:31 kg-fil kernel: ichsmb0: device timeout, status=0x00 Jul 27 16:33:02 kg-fil last message repeated 123 times Jul 27 16:33:27 kg-fil last message repeated 100 times Hmm, it doesn't look like it is working properly. I also tried loading smb first and ichsmb last, but nothing changes. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 Tor issues (Once More, with Feeling)
Fabian Keil [EMAIL PROTECTED] wrote: Fabian Keil [EMAIL PROTECTED] wrote: Peter Thoenen [EMAIL PROTECTED] wrote: To you have pf running? If so can you turn it off for a bit a see if you still crash. On my box I was getting all sorts of witness kbd backtraces on pf and since turning pf off (maybe a week ago), haven't crashed yet. Going to let it keep running unmetered for another 2 weeks and see if I crash or not. So far I didn't see a single PF related complaint from witness, but I'll try disabling PF in a few days anyway. It took a little longer than I thought, but I finally disabled PF today and switched to natd. Uptime was slightly above 25 hours. Compiling HEAD right now. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: filesystem full error with inumber
Sven Willenberger wrote: This was an upgrade from a 5.x system (UFS2); a full fsck did in fact fix the problem (for now). Because of past experience I recommend that you disable background fsck (it has a switch in /etc/rc.conf). There are failure scenarios with background fsck that can lead to symptoms similar to what you have experienced. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++ is the only current language making COBOL look good. -- Bertrand Meyer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: filesystem full error with inumber
Feargal Reilly [EMAIL PROTECTED] wrote: BTW, anybody know what the best method be for double-checking df's figures would be? du? No, du(1) only sees files that have links (i.e. directory entries). It doesn't see deleted files that occupy space as long as processes still have them open, which can make quite a difference. You can use the command lsof +L1 to check for such files. If there aren't any on the file system in question, then the number from du(1) should be pretty close to the number from df(1). The df(1) tool just displays the summary records from the file system. The only safe way to verify those numbers is to run fsck(8) manually on the file system (possibly twice). It will fix the summary records if necessary. Then run df(1) again. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. To this day, many C programmers believe that 'strong typing' just means pounding extra hard on the keyboard. -- Peter van der Linden ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
Mike Jakubik [EMAIL PROTECTED] wrote: Bruno Ducrot wrote: Could you please try (if you have a working smb device) # smbmsg -p Well, i don't think its being detected/supported. I tried loading all the smbus related kernel modules, but no device. Id Refs AddressSize Name 19 0xc040 2d1624 kernel 21 0xc06d2000 606acacpi.ko 33 0xc4dca000 2000 smbus.ko 41 0xc4dcc000 3000 iicsmb.ko 53 0xc4dcf000 3000 iicbus.ko 61 0xc4de4000 3000 smb.ko 71 0xc4df3000 3000 iic.ko 81 0xc4df6000 3000 if_ic.ko You should also try to load these kernel modules: alpm.ko, amdpm.ko, intpm.ko, viapm.ko However, dmesg seems to show that there is a SMBus device on the MB. pci0: serial bus, SMBus at device 31.3 (no driver attached) If none of the mentioned modules attach, please look at the output from pciconf -lv. What's the entry for your SMBus device (pci0:31:3)? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
On Thu, Jul 27, 2006 at 11:09:51AM -0400, Mike Jakubik wrote: Bruno Ducrot wrote: Could you please try (if you have a working smb device) # smbmsg -p Well, i don't think its being detected/supported. I tried loading all the smbus related kernel modules, but no device. Id Refs AddressSize Name 19 0xc040 2d1624 kernel 21 0xc06d2000 606acacpi.ko 33 0xc4dca000 2000 smbus.ko 41 0xc4dcc000 3000 iicsmb.ko 53 0xc4dcf000 3000 iicbus.ko 61 0xc4de4000 3000 smb.ko 71 0xc4df3000 3000 iic.ko 81 0xc4df6000 3000 if_ic.ko However, dmesg seems to show that there is a SMBus device on the MB. pci0: serial bus, SMBus at device 31.3 (no driver attached) It should be ichsmb with a ich7 southbridge IIRC, but there is a missing pci id onto sys/ichsmb/ichsmb_pci.c, (it should be 0x27da8086). Maybe the ich7 isn't supported yet. I don't have time to check more ATM. I'll look intel specs tomorrow. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
Jung-uk Kim wrote: FYI, see kern/85106: http://www.freebsd.org/cgi/query-pr.cgi?pr=85106 Great, i will try the patch shortly. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
Well, here are the patch results. The controller is detected: ichsmb0: Intel 82801GB (ICH7) SMBus controller port 0x1100-0x111f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 However communication does not seem to work: # smbmsg -p Probing for devices on /dev/smb0: Device @0x30: rw Device @0x32: rw ^C ichsmb0: device timeout, status=0x41 ichsmb0: device timeout, status=0x41 ichsmb0: device timeout, status=0x41 I also tried running mbmon using SMB, however this is the result: # mbmon -S No SMBus HWM available!! InitMBInfo: Unknown error: 0 Without any options, i get bogus temp values: # mbmon Temp.= 208.0, 0.0, 0.0; Rot.=0,0,0 Vcore = 3.62, 3.62; Volt. = 3.62, 5.21, 11.80, 1.13, 2.09 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
[EMAIL PROTECTED]:31:3: class=0x0c0500 card=0x618015d9 chip=0x24d38086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) SMBus Controller' class= serial bus subclass = SMBus 2006/7/27, Oliver Fromme [EMAIL PROTECTED]: Mike Jakubik [EMAIL PROTECTED] wrote: Bruno Ducrot wrote: Could you please try (if you have a working smb device) # smbmsg -p Well, i don't think its being detected/supported. I tried loading all the smbus related kernel modules, but no device. Id Refs AddressSize Name 19 0xc040 2d1624 kernel 21 0xc06d2000 606acacpi.ko 33 0xc4dca000 2000 smbus.ko 41 0xc4dcc000 3000 iicsmb.ko 53 0xc4dcf000 3000 iicbus.ko 61 0xc4de4000 3000 smb.ko 71 0xc4df3000 3000 iic.ko 81 0xc4df6000 3000 if_ic.ko You should also try to load these kernel modules: alpm.ko, amdpm.ko, intpm.ko, viapm.ko However, dmesg seems to show that there is a SMBus device on the MB. pci0: serial bus, SMBus at device 31.3 (no driver attached) If none of the mentioned modules attach, please look at the output from pciconf -lv. What's the entry for your SMBus device (pci0:31:3)? Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of kern_resource.c (calru changes)
On Wednesday 26 July 2006 18:31, Mike Jakubik wrote: Are there any plans to MFC the last few commits to kern_resource.c to -STABLE? I have a number of machines which flood the logs with calcru: negative runtime messages every time w, ps or top is used, so im hoping these may fix the issue. I think it involves an ABI breakage, so I doubt it. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
Have you tried using the firmware from iwi-firmware-kmod, rather than iwi-firmware. I am using the former on a Thinkpad T42 and it is working ok. -mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFC of kern_resource.c (calru changes)
John Baldwin wrote: On Wednesday 26 July 2006 18:31, Mike Jakubik wrote: Are there any plans to MFC the last few commits to kern_resource.c to -STABLE? I have a number of machines which flood the logs with calcru: negative runtime messages every time w, ps or top is used, so im hoping these may fix the issue. I think it involves an ABI breakage, so I doubt it. Thats unfortunate, as i just finished extensively testing the system with -CURRENT. There are no calcru messages, and no negative timestamps on processes occurring. In fact, everything is working perfectly. Is there anything that can be done to address this problem on -STABLE? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
Yes, I have. I just did another CVSup, and when I recompiled -kmod it did indeed put a bunch of .ko files in /build/modules, but a) I still get a whole bunch of Can't load firmware complaints, and b) it doesn't work. It goes through the DISCOVER process, but doesn't get any offers it recognizes. I've tried this both with an open DHCP and also with my parameters wired in. Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another gent who has a 2200G pci card and is having the same problem with STABLE. This all was working two weeks ago. On 7/27/06, Mark Willson [EMAIL PROTECTED] wrote: Have you tried using the firmware from iwi-firmware-kmod, rather than iwi-firmware. I am using the former on a Thinkpad T42 and it is working ok. -mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
From: Don Wilde [EMAIL PROTECTED] Yes, I have. I just did another CVSup, and when I recompiled -kmod it did indeed put a bunch of .ko files in /build/modules, but a) I still get a whole bunch of Can't load firmware complaints, and b) it doesn't work. It goes through the DISCOVER process, but doesn't get any offers it recognizes. I've tried this both with an open DHCP and also with my parameters wired in. Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another gent who has a 2200G pci card and is having the same problem with STABLE. This all was working two weeks ago. That is, indeed, a drag. b) is bad. We are using different hardware, which I guess could be a factor. When I can boot this thing under FreeBSD (work intervenes at present) I'll post what iwi-firmware-kmod put where. -mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nfs-client reveals MFC-if_re-probs (or vice-versa) ?
Hello, I have a curious problem which at first sight seems related to the end-June MFC of if_re : - I 'mount -o nfsv3,intr,noconn,-r=32768,-w=32768 -stable-server:/files/bsd /files/bsd ' - (/usr/ports and /usr/src are symlinks to /files/bsd/*) quickly after a portinstall/portversion etc. I get : nfs server -stable-server: not responding (and the corresponding process stuck in 'bo_wwa' according to top(1) ) - though I still can 'ping -stable-server' and even 'ssh me@-stable-server-IP' - -stable-server works ok with two other -stable clients (using if_bge) and all are compiled from the very same source-base (and -stable-server works fine as well with a linux-client) which seems to exclude nfsd-probs - a kernel from June the 11th works ok - downgrading if_re.c to revision 1.46.2.14 and if_rlreg.h to revision 1.51.2.3 makes the problem disappear - this is on my demo-notebook, I can test network stuff without much limitations; I just use nfs on it for upgrading world and ports. NB, same behaviour on amd64-stable and i386-stable (multi-boot same hardware) I can fill a PR if requested or feel free to contact me for further testing. Best regards, Arno PS: relevant pciconf info : [EMAIL PROTECTED]:8:0: class=0x02 card=0x47011558 chip=0x816910ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169 Gigabit Ethernet Adapter' class= network subclass = ethernet otherwise standard kernel conf with stripped unneeded drivers and extra : device cpufreq device atapicam device sound options TCP_DROP_SYNFIN (hint??) -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
[Please don't top-post] On Thursday 27 July 2006 21:01, Don Wilde wrote: Yes, I have. I just did another CVSup, and when I recompiled -kmod it did indeed put a bunch of .ko files in /build/modules, but a) I still get a whole bunch of Can't load firmware complaints, and b) it doesn't work. It goes through the DISCOVER process, but doesn't get any offers it recognizes. I've tried this both with an open DHCP and also with my parameters wired in. Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another gent who has a 2200G pci card and is having the same problem with STABLE. This all was working two weeks ago. Just to get the facts straight and assembled in one place: You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod installed and device iwi and options firmware built into your kernel? When do you get the Can't load firmware messages? What does kldstat [-v] say before and after that point? Can you try kldload iwi_bss before and see if that gets you up and running? On 7/27/06, Mark Willson [EMAIL PROTECTED] wrote: Have you tried using the firmware from iwi-firmware-kmod, rather than iwi-firmware. I am using the former on a Thinkpad T42 and it is working ok. -- /\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgpi7UJEn3h0i.pgp Description: PGP signature
Re: iwi(4) in RELENG_6
On 7/27/06, Max Laier [EMAIL PROTECTED] wrote: [Please don't top-post] On Thursday 27 July 2006 21:01, Don Wilde wrote: Yes, I have. I just did another CVSup, and when I recompiled -kmod it did indeed put a bunch of .ko files in /build/modules, but a) I still get a whole bunch of Can't load firmware complaints, and b) it doesn't work. It goes through the DISCOVER process, but doesn't get any offers it recognizes. I've tried this both with an open DHCP and also with my parameters wired in. Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another gent who has a 2200G pci card and is having the same problem with STABLE. This all was working two weeks ago. Just to get the facts straight and assembled in one place: You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod installed and device iwi and options firmware built into your kernel? When do you get the Can't load firmware messages? What does kldstat [-v] say before and after that point? Can you try kldload iwi_bss before and see if that gets you up and running? On 7/27/06, Mark Willson [EMAIL PROTECTED] wrote: Have you tried using the firmware from iwi-firmware-kmod, rather than iwi-firmware. I am using the former on a Thinkpad T42 and it is working ok. Hi, Max - I did so, and it appears that the module is already loaded. It seems that the problems occur because my system is also trying to load the old firmware somehow. A more disturbing issue is that my rc.conf seems to be being read twice. I see the kldstat reports (with my echo commands) being printed four times instead of the two I'm requesting. Attached are my rc.conf and dmesg. rc.cnf Description: Binary data dmesg.iwi Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Monitoring temperature with acpi (sysctls)
Someone mentionned that you can't reach the smbus on ASUS boards. That's because they turn it off in the BIOS. They turn it on and off as they need to read stuff for their SMI (well on some of their boards at least). you can turn it on again using pciconf. but I forget the exact incantation. (I've asked someone to send me the script so I'll have it later if anyone wants it) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
On 7/27/06, Don Wilde [EMAIL PROTECTED] wrote: On 7/27/06, Max Laier [EMAIL PROTECTED] wrote: [Please don't top-post] On Thursday 27 July 2006 21:01, Don Wilde wrote: Yes, I have. I just did another CVSup, and when I recompiled -kmod it did indeed put a bunch of .ko files in /build/modules, but a) I still get a whole bunch of Can't load firmware complaints, and b) it doesn't work. It goes through the DISCOVER process, but doesn't get any offers it recognizes. I've tried this both with an open DHCP and also with my parameters wired in. Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another gent who has a 2200G pci card and is having the same problem with STABLE. This all was working two weeks ago. Just to get the facts straight and assembled in one place: You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod installed and device iwi and options firmware built into your kernel? When do you get the Can't load firmware messages? What does kldstat [-v] say before and after that point? Can you try kldload iwi_bss before and see if that gets you up and running? On 7/27/06, Mark Willson [EMAIL PROTECTED] wrote: Have you tried using the firmware from iwi-firmware-kmod, rather than iwi-firmware. I am using the former on a Thinkpad T42 and it is working ok. Hi, Max - I did so, and it appears that the module is already loaded. It seems that the problems occur because my system is also trying to load the old firmware somehow. A more disturbing issue is that my rc.conf seems to be being read twice. I see the kldstat reports (with my echo commands) being printed four times instead of the two I'm requesting. Attached are my rc.conf and dmesg. Okay, I've gotten it working with all encryption off (raw DHCP). All the nasty messages went away, so I'll see what's changed in the ifconfig options. ifconfig_iwi0=DHCP ssid rewired channel 11 authmode shared weptxkey 1 wepmode on wepkey 0x1234567890 Can anybody spot it off the top? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: scan stuck with if_iwi(4)
Sam Leffler wrote: Andrew Thompson wrote: On Wed, Jul 26, 2006 at 01:28:12PM -0700, Sam Leffler wrote: Henrik Brix Andersen wrote: Oh? Sounds interesting, where can I find these patches? The work has always been in perforce.freebsd.org; look in the sam_wifi branch. The code will not hit head until folks show up to fix legacy drivers that use net80211. I got stuck holding the bag when I committed the wpa support and it ain't going to happen again. Do you have a list of drivers that are stalling this? The changes decouple scanning from the net80211 state machine so any driver that uses ieee80211_new_state is affected: tubby% grep -l ieee80211_new_state */*.c ath/if_ath.c awi/awi.c ipw/if_ipw.c iwi/if_iwi.c ral/rt2560.c ral/rt2661.c usb/if_ural.c wi/if_wi.c I know how to convert ath and ral. iwi and ipw might not be too bad now that they've been changed to not abuse the state machine so much. awi, ural, and wi will break. ural might be ok after the new usb stack comes in but that's not clear. So I guess I'd take responsibility for ath and ral and want help with all other drivers. I forgot the other key item missing from the above list: ndis. It bypasses the net80211 api's lots of places and frobs things directly so converting may be a big job--hard to say until someone tries it. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iwi(4) in RELENG_6
On 7/27/06, Don Wilde [EMAIL PROTECTED] wrote: On 7/27/06, Don Wilde [EMAIL PROTECTED] wrote: On 7/27/06, Max Laier [EMAIL PROTECTED] wrote: [Please don't top-post] On Thursday 27 July 2006 21:01, Don Wilde wrote: Yes, I have. I just did another CVSup, and when I recompiled -kmod it did indeed put a bunch of .ko files in /build/modules, but a) I still get a whole bunch of Can't load firmware complaints, and b) it doesn't work. It goes through the DISCOVER process, but doesn't get any offers it recognizes. I've tried this both with an open DHCP and also with my parameters wired in. Hardware notes: Dell 6100 Inspiron with 2200G iwi. I have heard from another gent who has a 2200G pci card and is having the same problem with STABLE. This all was working two weeks ago. Just to get the facts straight and assembled in one place: You are running a somewhat recent RELENG_6, have net/iwi-firmware-kmod installed and device iwi and options firmware built into your kernel? When do you get the Can't load firmware messages? What does kldstat [-v] say before and after that point? Can you try kldload iwi_bss before and see if that gets you up and running? On 7/27/06, Mark Willson [EMAIL PROTECTED] wrote: Have you tried using the firmware from iwi-firmware-kmod, rather than iwi-firmware. I am using the former on a Thinkpad T42 and it is working ok. Hi, Max - I did so, and it appears that the module is already loaded. It seems that the problems occur because my system is also trying to load the old firmware somehow. A more disturbing issue is that my rc.conf seems to be being read twice. I see the kldstat reports (with my echo commands) being printed four times instead of the two I'm requesting. Attached are my rc.conf and dmesg. Okay, I've gotten it working with all encryption off (raw DHCP). All the nasty messages went away, so I'll see what's changed in the ifconfig options. ifconfig_iwi0=DHCP ssid rewired channel 11 authmode shared weptxkey 1 wepmode on wepkey 0x1234567890 Can anybody spot it off the top? By removing the hardwired 'channel 11 authmode shared' from both sides, I have been able to connect successfully with WEP authentication. Thanks for all your suggestions, guys! :D ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird problems with 'pf' (on both 5.x and 6.x)
It happens that I noticed two odd networking problems recently.
One of them is easily reproducible, and I have it tracked down
to one innocuous-looking line in my /etc/pf.conf. The other
is a problem in a chat server that I run, with a few hundred
people on it, and is much more of a hassle to reproduce. But
turning off 'pf' to solve the first problem seems to have
also solved the second problem, so I assume both problems
come from the same culprit.
Once I figured out how to reproduce the problem, it seems so
easy to reproduce that I find it odd that no one else has
run into it. But I also do not notice any PR's that seemed
to describe the problem. I'd appreciate it if people would
try to duplicate the problem on some other machines.
This problem has been seen on:
5.x-stable as built on Mon Jul 24
6.x-stable as built on Mon Jul 17
(as well as several earlier snapshots of both 5.x and 6.x).
I have a freebsd box which is the server for a print queue
named 'bill', and is running pf. I have other machines which
reference that queue. It seems that machines on the same
subnet as the server-box do not exhibit the problem. But
for other machines, if I do 'lpq -Pbill' twice in rapid
succession, then the second one will hang.
After some futzing around, I determined that if my pf.conf
has only the lines:
# Filtering: the implicit first two rules are
#pass in all
#pass out all
then I can do many many lpq's in a row, without any trouble.
But if I restart pf after adding these lines to pf.conf:
# Allow all outgoing tcp and udp connections and keep state
pass out quick proto { tcp, udp } all keep state
then I have the problem where the second 'lpq' from a remote
host will hang, if it is done right after the first one.
That's right. I add a rule which just does quick passing
for *outbound* connections, and somehow that screws up
(blocks?) *incoming* connections. I have no rules which
should block any packets at all, so my guess is that some
packets are getting lost, delayed, or corrupted somewhere.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird problems with 'pf' (on both 5.x and 6.x)
At 9:07 PM -0400 7/27/06, Garance A Drosihn wrote:
But if I restart pf after adding these lines to pf.conf:
# Allow all outgoing tcp and udp connections and keep state
pass out quick proto { tcp, udp } all keep state
then I have the problem where the second 'lpq' from a remote
host will hang, if it is done right after the first one.
The client-machine which is doing the lpq is a solaris
machine, so here is the 'snoop' output from that side
of things. Disclaimer: I'm not a networking expert,
so I'm hoping someone else will find this a lot more
obvious than I do.
Here's the packets from the first 'lpq', with various
names changed to protect the innocent (and to reduce
the wrapping a little bit...):
1 0.0 lpq-client - print-serv ETHER Type=0800 (IP), size = 62 bytes
1 0.0 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=48, ID=13267
1 0.0 lpq-client - print-serv TCP D=515 S=1023 Syn
Seq=1503722122 Len=0 Win=24820 Options=nop,nop,sackOK,mss 1460
1 0.0 lpq-client - print-serv PRINTER C port=1023
2 0.00068 print-serv - lpq-client ETHER Type=0800 (IP), size = 62 bytes
2 0.00068 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=48, ID=4007
2 0.00068 print-serv - lpq-client TCP D=1023 S=515 Syn
Ack=1503722123 Seq=1874442309 Len=0 Win=65535 Options=mss
1460,sackOK,eol
2 0.00068 print-serv - lpq-client PRINTER R port=1023
3 0.00072 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
3 0.00072 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13268
3 0.00072 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442310 Seq=1503722123 Len=0 Win=24820
3 0.00072 lpq-client - print-serv PRINTER C port=1023
4 0.00088 lpq-client - print-serv ETHER Type=0800 (IP), size = 63 bytes
4 0.00088 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=49, ID=13269
4 0.00088 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442310 Seq=1503722123 Len=9 Win=24820
4 0.00088 lpq-client - print-serv PRINTER C port=1023 \3bill\n
5 0.03003 print-serv - lpq-client ETHER Type=0800 (IP), size = 132 bytes
5 0.03003 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=118, ID=4045
5 0.03003 print-serv - lpq-client TCP D=1023 S=515
Ack=1503722132 Seq=1874442310 Len=78 Win=65535
5 0.03003 print-serv - lpq-client PRINTER R port=1023 Warning: bill is
6 0.03014 print-serv - lpq-client ETHER Type=0800 (IP), size = 60 bytes
6 0.03014 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=40, ID=4046
6 0.03014 print-serv - lpq-client TCP D=1023 S=515 Fin
Ack=1503722132 Seq=1874442388 Len=0 Win=65535
6 0.03014 print-serv - lpq-client PRINTER R port=1023
7 0.03020 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
7 0.03020 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13270
7 0.03020 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442388 Seq=1503722132 Len=0 Win=24820
7 0.03020 lpq-client - print-serv PRINTER C port=1023
8 0.03022 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
8 0.03022 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13271
8 0.03022 lpq-client - print-serv TCP D=515 S=1023
Ack=1874442389 Seq=1503722132 Len=0 Win=24820
8 0.03022 lpq-client - print-serv PRINTER C port=1023
9 0.03074 lpq-client - print-serv ETHER Type=0800 (IP), size = 54 bytes
9 0.03074 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=40, ID=13272
9 0.03074 lpq-client - print-serv TCP D=515 S=1023 Fin
Ack=1874442389 Seq=1503722132 Len=0 Win=24820
9 0.03074 lpq-client - print-serv PRINTER C port=1023
10 0.03132 print-serv - lpq-client ETHER Type=0800 (IP), size = 60 bytes
10 0.03132 print-serv - lpq-client IP D=128.113.002.002
S=128.113.000.001 LEN=40, ID=4047
10 0.03132 print-serv - lpq-client TCP D=1023 S=515
Ack=1503722133 Seq=1874442389 Len=0 Win=65534
10 0.03132 print-serv - lpq-client PRINTER R port=1023
and then here is the packets from the second 'lpq', done
right after the first one. It looks like the problem is
in the initial handshaking to get the connection started:
11 7.19194 lpq-client - print-serv ETHER Type=0800 (IP), size = 62 bytes
11 7.19194 lpq-client - print-serv IP D=128.113.000.001
S=128.113.002.002 LEN=48, ID=13273
11 7.19194 lpq-client - print-serv TCP D=515 S=1023 Syn
Seq=1505511645 Len=0 Win=24820
Re: Weird problems with 'pf' (on both 5.x and 6.x)
At 9:18 PM -0400 7/27/06, Garance A Drosihn wrote:
At 9:07 PM -0400 7/27/06, Garance A Drosihn wrote:
But if I restart pf after adding these lines to pf.conf:
# Allow all outgoing tcp and udp connections and keep state
pass out quick proto { tcp, udp } all keep state
then I have the problem where the second 'lpq' from a remote
host will hang, if it is done right after the first one.
The client-machine which is doing the lpq is a solaris
machine, so here is the 'snoop' output from that side
of things.
It occurred to me that it might be more informative to
see the transaction from the *freebsd* side of things,
since that's the machine running pf! So, here is a
similar set of two lpq's, as seen from the print-server
side of the connection. It seems to be telling the
same basic story, as far as I can tell.
aside
But if there is a bug somewhere, then might it
be that the same bug which effects 'pf' would
also confuse what tcpdump would report, when
running tcpdump on the same machine?
/aside
(316) santropez/root # tcpdump -X -r
/tmp/gadchecks/all-060727.212311 host lpq-client
reading from file /tmp/gadchecks/all-060727.212311, link-type EN10MB (Ethernet)
21:23:32.175093 IP (tos 0x0, ttl 63, id 53775, offset 0, flags [DF],
proto: TCP (6), length: 48) lpq-client.1023 print-serv.printer: S,
cksum 0x6b2c (correct), 2119630748:2119630748(0) win 24820
nop,nop,sackOK,mss 1460
0x: 4500 0030 d20f 4000 3f06 36af 8071 1985 [EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ff9c .q..~V..
0x0020: 7002 60f4 6b2c 0101 0402 0204 05b4 p.`.k,..
21:23:32.175205 IP (tos 0x0, ttl 64, id 4488, offset 0, flags [DF],
proto: TCP (6), length: 48) print-serv.printer lpq-client.1023: S,
cksum 0x0bfa (correct), 2140553600:2140553600(0) ack 2119630749 win
65535 mss 1460,sackOK,eol
0x: 4500 0030 1188 4000 4006 f636 8071 18a2 [EMAIL
PROTECTED]@..6.q..
0x0010: 8071 1985 0203 03ff 7f96 4180 7e56 ff9d .qA.~V..
0x0020: 7012 0bfa 0204 05b4 0402 p...
21:23:32.175787 IP (tos 0x0, ttl 63, id 53776, offset 0, flags [DF],
proto: TCP (6), length: 40) lpq-client.1023 print-serv.printer: .,
cksum 0xd6c8 (correct), 1:1(0) ack 1 win 24820
0x: 4500 0028 d210 4000 3f06 36b6 8071 1985 E..([EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ff9d 7f96 4181 .q..~VA.
0x0020: 5010 60f4 d6c8 P.`.UU
21:23:32.175935 IP (tos 0x0, ttl 63, id 53777, offset 0, flags [DF],
proto: TCP (6), length: 49) lpq-client.1023 print-serv.printer: P,
cksum 0xc80d (correct), 1:10(9) ack 1 win 24820
0x: 4500 0031 d211 4000 3f06 36ac 8071 1985 [EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ff9d 7f96 4181 .q..~VA.
0x0020: 5018 60f4 c80d 0370 6269 6c6c 3264 P.`..bill
0x0030: 0a .
21:23:32.204946 IP (tos 0x0, ttl 64, id 4526, offset 0, flags [DF],
proto: TCP (6), length: 118) print-serv.printer lpq-client.1023: P,
cksum 0x5bcb (correct), 1:79(78) ack 10 win 65535
0x: 4500 0076 11ae 4000 4006 f5ca 8071 18a2 [EMAIL
PROTECTED]@q..
0x0010: 8071 1985 0203 03ff 7f96 4181 7e56 ffa6 .qA.~V..
0x0020: 5018 5bcb 5761 726e 696e 673a P...[...Warning:
0x0030: 2070 6269 6c6c 3264 2069 7320 646f 776e .bill.is.down
0x0040: 3a20 5468 6973 2071 7565 7565 2069 7320 :.This.queue.is.
0x0050: 666f 7220 4761 7261 6e63 6520 7465 7374 for.Garance.test
0x0060: 696e 672e 2073 742f 3678 0a6e 6f20 656e ing..st/6x.no.en
0x0070: 7472 6965 730a tries.
21:23:32.204988 IP (tos 0x0, ttl 64, id 4527, offset 0, flags [DF],
proto: TCP (6), length: 40) print-serv.printer lpq-client.1023: F,
cksum 0x3765 (correct), 79:79(0) ack 10 win 65535
0x: 4500 0028 11af 4000 4006 f617 8071 18a2 E..([EMAIL
PROTECTED]@q..
0x0010: 8071 1985 0203 03ff 7f96 41cf 7e56 ffa6 .qA.~V..
0x0020: 5011 3765 P...7e..
21:23:32.205701 IP (tos 0x0, ttl 63, id 53778, offset 0, flags [DF],
proto: TCP (6), length: 40) lpq-client.1023 print-serv.printer: .,
cksum 0xd671 (correct), 10:10(0) ack 79 win 24820
0x: 4500 0028 d212 4000 3f06 36b4 8071 1985 E..([EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ffa6 7f96 41cf .q..~VA.
0x0020: 5010 60f4 d671 P.`..q..UU
21:23:32.205755 IP (tos 0x0, ttl 63, id 53779, offset 0, flags [DF],
proto: TCP (6), length: 40) lpq-client.1023 print-serv.printer: .,
cksum 0xd670 (correct), 10:10(0) ack 80 win 24820
0x: 4500 0028 d213 4000 3f06 36b3 8071 1985 E..([EMAIL PROTECTED]
0x0010: 8071 18a2 03ff 0203 7e56 ffa6 7f96 41d0 .q..~VA.
