Re: Reproduceable freeze with quotas enabled
Hello, Attila Nagy wrote: Robert Watson wrote: On Thu, 3 Nov 2005, Attila Nagy wrote: I have an easily (at least to me) reproduceable freeze with both 6-STABLE and 7-CURRENT on an amd64 SMP machine. What I do is simply copy a lot of directories, files and symlinks with different uids from another machine to this one, using rsync. This is probably a vnode lock leak or deadlock. As it looks like you have both the ability to get into the debugger and also a serial or other remote console, the output of: show allpcpu alltrace show lockedvnods show allocks would be helpful. There are also options DEBUG_LOCKS which extends the debugging information available via show lockedvnods with information about where the lock was acquired, which can be quite helpful. http://people.fsn.hu/~bra/freebsd/crash-20051105/crashlog I've put all together in this file. Tell me please if I can do anything to make the issue more clear. Thanks, -- Attila Nagy e-mail: [EMAIL PROTECTED] Adopt a directory on our free software phone: +3630 306 6758 server! http://www.fsn.hu/?f=brick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel source hacking
On Fri, 4 Nov 2005, Joao Barros wrote: On 11/4/05, Robert Watson [EMAIL PROTECTED] wrote: On Thu, 3 Nov 2005, M. Warner Losh wrote: : Also, is there a page with other tasks for kernel neophytes like me? I : looked for some such page but I couldn't find any. phk used to have a /jkh/ page, or Junior Kernel Hacker page. Don't know if that's still that way or not. Now that we have a FreeBSD Developer wiki, it may make sense to move the page there so it can be more easily reached and maintained by a broader set of developers? Could you please provide the link for the Wiki? Thanks. A test wiki for developer use has been set up here: http://wikitest.FreeBSD.org/ Its primary use so far has been to host content for the Google Summer of Code students, although other content is also starting to make it onto the Wiki. I think the primary reason it's still considered experimental is that it is hosted outside the FreeBSD.org cluster. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel source hacking
On 11/5/05, Robert Watson [EMAIL PROTECTED] wrote: On Fri, 4 Nov 2005, Joao Barros wrote: On 11/4/05, Robert Watson [EMAIL PROTECTED] wrote: On Thu, 3 Nov 2005, M. Warner Losh wrote: : Also, is there a page with other tasks for kernel neophytes like me? I : looked for some such page but I couldn't find any. phk used to have a /jkh/ page, or Junior Kernel Hacker page. Don't know if that's still that way or not. Now that we have a FreeBSD Developer wiki, it may make sense to move the page there so it can be more easily reached and maintained by a broader set of developers? Could you please provide the link for the Wiki? Thanks. A test wiki for developer use has been set up here: http://wikitest.FreeBSD.org/ Its primary use so far has been to host content for the Google Summer of Code students, although other content is also starting to make it onto the Wiki. I think the primary reason it's still considered experimental is that it is hosted outside the FreeBSD.org cluster. Robert N M Watson I was there earlier when you mentioned a link to the MySQL section on the latest MySQL performance on FreeBSD thread on stable@ (I think) but never got around to see the rest of the wiki. Thank you and Wesley for the reply. -- Joao Barros ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: allocating 14KB memory per packet compression/decompression results in v
From: Giorgos Keramidas [EMAIL PROTECTED] On 2005-11-03 22:56, kamal kc [EMAIL PROTECTED] wrote: since i am using the adaptive LZW compression scheme it requires construction of string table for compression/decompression. So an ip packet of size 1500 bytes requires a table of size (4KB + 4KB + 2KB = 12KB). I may be stating the obvious or something totally wrong, but couldn't the string table be constructed once instead of each time a packet goes down? It is my intuition that this would perform much much better than re-doing the work of the string table each time a packet goes out. No, the table changes as data is compressed. It records the knowledge about the strings that have already occured in the data. Keeping the table between the packets would improve the compression but the packets would have to be transmitted through a reliable medium since to decompress a packet you would have to decompress all the preceding packets first (essentially you get a stream compression). To keep the packets separate, the compression state must be reset between them. But of course resetting the compression state does not mean that the memory should be deallocated. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: allocating 14KB memory per packet compression/decompression results in v
On 2005-11-04 11:14, Sergey Babkin [EMAIL PROTECTED] wrote: Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2005-11-03 22:56, kamal kc [EMAIL PROTECTED] wrote: since i am using the adaptive LZW compression scheme it requires construction of string table for compression/decompression. So an ip packet of size 1500 bytes requires a table of size (4KB + 4KB + 2KB = 12KB). I may be stating the obvious or something totally wrong, but couldn't the string table be constructed once instead of each time a packet goes down? It is my intuition that this would perform much much better than re-doing the work of the string table each time a packet goes out. No, the table changes as data is compressed. It records the knowledge about the strings that have already occured in the data. Keeping the table between the packets would improve the compression but the packets would have to be transmitted through a reliable medium since to decompress a packet you would have to decompress all the preceding packets first (essentially you get a stream compression). Ah, yes, I see now. You're right of course. I was thinking of something resembling a compressed tunnel when I wrote the reply, but that doesn't work with IP very well, unless some other sort of encapsulation is at work. To keep the packets separate, the compression state must be reset between them. But of course resetting the compression state does not mean that the memory should be deallocated. Very true :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
twe and giant
Hello all, I was just wondering about this... I recently bumped a soon-to-be production box to 6.0 as it seems like upgrading now is easier than doing it the week after the box goes into production (it's amazing how the release engineering team knows to schedule this way...:). One thing I noticed in reviewing the boot messages is that twe is still under the giant lock: twe0: 3ware Storage Controller. Driver version 1.50.01.002 port 0x2860-0x286f mem 0xf400-0xf47f irq 17 at device 13.0 on pci0 twe0: [GIANT-LOCKED] twe0: 4 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 I bring this up because I could have sworn that I read here or elsewhere that this driver was revamped. I also could have sworn that at some point in 5.x it was not under giant. Maybe I'm imagining things... Anyhow, does anyone know the status of this, and also is there a central repository that tracks changes like this that I can watch? Thanks, Charles ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twe and giant
Charles Sprickman wrote: Hello all, I was just wondering about this... I recently bumped a soon-to-be production box to 6.0 as it seems like upgrading now is easier than doing it the week after the box goes into production (it's amazing how the release engineering team knows to schedule this way...:). One thing I noticed in reviewing the boot messages is that twe is still under the giant lock: twe0: 3ware Storage Controller. Driver version 1.50.01.002 port 0x2860-0x286f mem 0xf400-0xf47f irq 17 at device 13.0 on pci0 twe0: [GIANT-LOCKED] twe0: 4 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 I bring this up because I could have sworn that I read here or elsewhere that this driver was revamped. I also could have sworn that at some point in 5.x it was not under giant. Maybe I'm imagining things... Anyhow, does anyone know the status of this, and also is there a central repository that tracks changes like this that I can watch? Thanks, Charles I have some old patches that lock twe. They aren't quite complete or right due to an edge case with DMA handling. I'll probably dust them off and finish them soon. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: twe and giant
On Sat, Nov 05, 2005 at 06:36:56PM -0500, Charles Sprickman wrote: Hello all, I was just wondering about this... I recently bumped a soon-to-be production box to 6.0 as it seems like upgrading now is easier than doing it the week after the box goes into production (it's amazing how the release engineering team knows to schedule this way...:). One thing I noticed in reviewing the boot messages is that twe is still under the giant lock: twe0: 3ware Storage Controller. Driver version 1.50.01.002 port 0x2860-0x286f mem 0xf400-0xf47f irq 17 at device 13.0 on pci0 twe0: [GIANT-LOCKED] twe0: 4 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 I bring this up because I could have sworn that I read here or elsewhere that this driver was revamped. I also could have sworn that at some point in 5.x it was not under giant. Maybe I'm imagining things... Under later 5.x the message was not reported except under boot -v because too many people were seeing the message and panicking thinking that it was a regression compared to 4.x, since 4.x didn't say anything about giant locking (but of course under 4.x the ENTIRE KERNEL was giant locked). Anyhow, does anyone know the status of this, and also is there a central repository that tracks changes like this that I can watch? Yes, you can subscribe to the cvs mailing lists. Kris pgp7cXa8QmEDL.pgp Description: PGP signature
