freebsd-current

• Date Index

• [PATCH] HEADSUP: kbdmux(4)/syscons(4) patch is about to hit the tree, Maksim Yevmenkin
• -current panics when usb device is detached, Maksim Yevmenkin
• Re: ATI on FreeBSD! FireGL Linux Driver Port, Alexander I. Mogilny
• world børken ?, Poul-Henning Kamp
• make buildworld error (/usr/src/lib/libc/rpc/getpublickey.c), Mike Jakubik
• bsnmpd breaks buildworld, Steve Kargl
  • Re: bsnmpd breaks buildworld, Steve Kargl
    • Re: bsnmpd breaks buildworld, Ruslan Ermilov
• Fatal trap 12: page fault while in kernel mode in 5.5-PRERELEASE with IPSEC/isakmpd, David Boyd
• [PATCH] upcoming kbdmux(4) integration, Maksim Yevmenkin
  • Re: [PATCH] upcoming kbdmux(4) integration, Jonathan Noack
• [PATCH] ukbd(4) - request for comments, Maksim Yevmenkin
• 64-bit SNMP interface counters, Harti Brandt
• Kern_symlink(...) is not setting vattr.va_type, Rohit Jalan
  • Re: Kern_symlink(...) is not setting vattr.va_type, David Malone
• today's 6.1 would not boot here, Mikhail T.
• Dumping prior to dumpon(8) (Re: cvs commit: src/sbin/dumpon dumpon.8), Kris Kennaway
• Optimized kernel copying functions, Attilio Rao
• /bin/sh doesn't run autoconf'ied configure scripts correctly, Kash Pande
  • Re: /bin/sh doesn't run autoconf'ied configure scripts correctly, Kris Kennaway
    • Re: /bin/sh doesn't run autoconf'ied configure scripts correctly, Doug Barton
  • Re: /bin/sh doesn't run autoconf'ied configure scripts correctly, Dag-Erling Smørgrav
    • Re: /bin/sh doesn't run autoconf'ied configure scripts correctly, Mark Kirkwood
      • Re: /bin/sh doesn't run autoconf'ied configure scripts correctly, Dag-Erling Smørgrav
      • Re: /bin/sh doesn't run autoconf'ied configure scripts correctly, Mark Kirkwood
  • Re: /bin/sh doesn't run autoconf'ied configure scripts correctly, Jeremy Messenger
• "fsck -fB" panics: snapacct_ufs2: bad block, Peter Jeremy
• ATA DMA dump failures: take 2, Dmitry Pryanishnikov
• RFC: separate 3dfx_linux module, Yar Tikhiy
  • Re: RFC: separate 3dfx_linux module, Scott Long
    • Re: RFC: separate 3dfx_linux module, Coleman Kane
      • Re: RFC: separate 3dfx_linux module, Yar Tikhiy
      • Re: RFC: separate 3dfx_linux module, Scott Long
      • Re: RFC: separate 3dfx_linux module, Coleman Kane
      • Re: RFC: separate 3dfx_linux module, Scott Long
      • Re: RFC: separate 3dfx_linux module, Coleman Kane
      • Re: RFC: separate 3dfx_linux module, Scott Long
      • Re: RFC: separate 3dfx_linux module, Coleman Kane
• [PATCH] kbdmux(4) update, Maksim Yevmenkin
  • Re: [PATCH] kbdmux(4) update, Markus Brueffer
    • Re: [PATCH] kbdmux(4) update, Maksim Yevmenkin
      • Re: [PATCH] kbdmux(4) update, Markus Brueffer
      • Re: [PATCH] kbdmux(4) update, Scott Long
      • Re: [PATCH] kbdmux(4) update, Maksim Yevmenkin
      • Re: [PATCH] kbdmux(4) update, Markus Brueffer
      • Re: [PATCH] kbdmux(4) update, Maksim Yevmenkin
  • Message not available
    • Re: [PATCH] kbdmux(4) update, Maksim Yevmenkin
  • Re: [PATCH] kbdmux(4) update, Craig Boston
• CFT: src/tools/tools/npcus, Sam Leffler
  • Re: CFT: src/tools/tools/npcus, Sam Leffler
  • Re: CFT: src/tools/tools/npcus, John Baldwin
• multimedia/libxine fails with recent autotools update, Stephane E. Potvin
• panic: PHOLD of exiting process, Peter Holm
  • Re: panic: PHOLD of exiting process, John Baldwin
    • Re: panic: PHOLD of exiting process, Peter Holm
      • Re: panic: PHOLD of exiting process, John Baldwin
• typo in dump manual?, Andriy Tkachuk
  • Re: typo in dump manual?, Giorgos Keramidas
    • Re: typo in dump manual?, Giorgos Keramidas
• FreeBSD-Current on hp nc6220, eric
  • Re: FreeBSD-Current on hp nc6220, Scot Hetzel
• ping (DUP!) in FreeBSD 5.4, Nik
  • Re: ping (DUP!) in FreeBSD 5.4, Dmitry Pryanishnikov
    • Re: ping (DUP!) in FreeBSD 5.4, Jim Thompson
      • Re: ping (DUP!) in FreeBSD 5.4, Dmitry Pryanishnikov
      • Re: ping (DUP!) in FreeBSD 5.4, Nik
• Page fault in thr_exit(), Kris Kennaway
• The sixty second pmc howto, Robert Watson
  • Re: The sixty second pmc howto, Andrew Gallatin
    • Re: The sixty second pmc howto, Robert Watson
      • Re: The sixty second pmc howto, Andrew Gallatin
      • Re: The sixty second pmc howto, Joseph Koshy
• Networking Puzzle, Cian Hughes
  • Re: Networking Puzzle, Alexandre \"Sunny\" Kovalenko
  • Re: Networking Puzzle, Marcin Jessa
• WARNING: attempt to net_add_domain(netgraph) after domainfinalize(), Mike Jakubik
  • Re: WARNING: attempt to net_add_domain(netgraph) after domainfinalize(), Gleb Smirnoff
• proposed /sbin/init permission change, Luigi Rizzo
  • Re: proposed /sbin/init permission change, Thomas Quinot
• Re: Can't resolve defined(?) symbol after ELF symbol versioning, othermark
• NanoBSD don't boot., Peter Ankerstål
  • Re: NanoBSD don't boot., Dag-Erling Smørgrav
• [PATCH] possible fix for the runtime going backwards warnings, John Baldwin
  • Re: [PATCH] possible fix for the runtime going backwards warnings, Stefan Ehmann
  • Re: [PATCH] possible fix for the runtime going backwards warnings, Kris Kennaway
    • Re: [PATCH] possible fix for the runtime going backwards warnings, Andrey Chernov
    • Re: [PATCH] possible fix for the runtime going backwards warnings, John Baldwin
      • Re: [PATCH] possible fix for the runtime going backwards warnings, Andrey Chernov
      • Re: [PATCH] possible fix for the runtime going backwards warnings, John Baldwin
      • Re: [PATCH] possible fix for the runtime going backwards warnings, Andrey Chernov
      • Re: [PATCH] possible fix for the runtime going backwards warnings, Kazuaki Oda
      • Re: [PATCH] possible fix for the runtime going backwards warnings, John Baldwin
      • Re: [PATCH] possible fix for the runtime going backwards warnings, Kris Kennaway
      • Re: [PATCH] possible fix for the runtime going backwards warnings, Patrick Bowen
• partition for GELI disk, Balgansuren Batsukh
  • Re: partition for GELI disk, Ulrich Spoerlein
    • Re: partition for GELI disk, Balgansuren Batsukh
    • Re: partition for GELI disk, Pawel Jakub Dawidek
      • Re: partition for GELI disk, Ulrich Spoerlein
      • Re: partition for GELI disk, Dag-Erling Smørgrav
• GELI boot on root partition, Balgansuren Batsukh
  • Re: GELI boot on root partition, Alex Dupre
    • Re: GELI boot on root partition, Balgansuren Batsukh
• mount_smbfs trouble after cvsup, Bachilo Dmitry
  • Re: mount_smbfs trouble after cvsup, Tai-hwa Liang
    • Re: mount_smbfs trouble after cvsup, Gavin Atkinson
• netgroup limits on -current ... [mountd(8)], Wilkinson, Alex
  • Re: netgroup limits on -current ... [mountd(8)], Vladimir Egorin
    • Re: netgroup limits on -current ... [mountd(8)], Wilkinson, Alex
  • <Possible follow-ups>
  • RE: netgroup limits on -current ... [mountd(8)], Thyer, Matthew
• dhclient existing when run early in startup, Kevin Oberman
  • Re: dhclient existing when run early in startup, Brooks Davis
    • Re: dhclient existing when run early in startup, Kevin Oberman
      • Re: dhclient existing when run early in startup, Tobias Roth
      • Re: dhclient existing when run early in startup, Kevin Oberman
      • Re: dhclient existing when run early in startup, Tobias Roth
• Lots of calcru: runtime went backwards, never saw it before, Andrey Chernov
  • Re: Lots of calcru: runtime went backwards, never saw it before, Giorgos Keramidas
    • Re: Lots of calcru: runtime went backwards, never saw it before, Kris Kennaway
      • Re: Lots of calcru: runtime went backwards, never saw it before, Andrey Chernov
      • Re: Lots of calcru: runtime went backwards, never saw it before, Kris Kennaway
      • Re: Lots of calcru: runtime went backwards, never saw it before, Giorgos Keramidas
    • Re: Lots of calcru: runtime went backwards, never saw it before, Andrey Chernov
  • Re: Lots of calcru: runtime went backwards, never saw it before, Jiawei Ye
    • Re: Lots of calcru: runtime went backwards, never saw it before, Andrey Chernov
      • Re: Lots of calcru: runtime went backwards, never saw it before, Kris Kennaway
• kernel panic / acpi problem., Martin Wilke
  • Re: kernel panic / acpi problem., Ben Kaduk
    • Re: kernel panic / acpi problem., Martin Wilke
  • <Possible follow-ups>
  • kernel panic / acpi problem., Martin Wilke
• bge(4) problem, Peter Ross
  • Re: bge(4) problem, Gleb Smirnoff
    • Re: bge(4) problem, Peter Ross
      • Re: bge(4) problem, David Barbero
      • Re: bge(4) problem, Geoffrey Giesemann
• no dump on a gmirror ?, Thierry Herbelot
  • RE: no dump on a gmirror ?, Larry Rosenman
    • Re: no dump on a gmirror ?, Doug Barton
      • RE: no dump on a gmirror ?, Larry Rosenman
      • Re: no dump on a gmirror ?, Marcin Jessa
      • RE: no dump on a gmirror ?, Larry Rosenman
• em0: Fatal trap 12: page fault while in kernel mode, Denis Shaposhnikov
  • Re: em0: Fatal trap 12: page fault while in kernel mode, Gleb Smirnoff
    • Re: em0: Fatal trap 12: page fault while in kernel mode, Denis Shaposhnikov
  • Re: em0: Fatal trap 12: page fault while in kernel mode, Denis Shaposhnikov
    • Re: em0: Fatal trap 12: page fault while in kernel mode, Gleb Smirnoff
• USB and clear endpoint stall, Fredrik Lindberg
  • Re: USB and clear endpoint stall, Ian Dowse
    • Re: USB and clear endpoint stall, Ian Dowse
      • Re: USB and clear endpoint stall, Fredrik Lindberg
• attaching a keyboard later, Oliver Lehmann
  • Re: attaching a keyboard later, Brian Candler
    • Re: attaching a keyboard later, Alain Hebert
      • Re: attaching a keyboard later, Brian Candler
      • Re: attaching a keyboard later, Chuck Swiger
      • Re: attaching a keyboard later, Brian Candler
      • Re: attaching a keyboard later, Chuck Swiger
      • Re: attaching a keyboard later, Alain Hebert
• MFC of "Unbreak Promise SATAII/150 controllers" ?, Thierry Herbelot
  • Re: MFC of "Unbreak Promise SATAII/150 controllers" ?, Søren Schmidt
    • Re: MFC of "Unbreak Promise SATAII/150 controllers" ?, Thierry Herbelot
      • Re: MFC of "Unbreak Promise SATAII/150 controllers" ?, Søren Schmidt
      • Re: MFC of "Unbreak Promise SATAII/150 controllers" ?, Thierry Herbelot
• Is HEAD broken for anybody else?, Giorgos Keramidas
  • Re: Is HEAD broken for anybody else?, Giorgos Keramidas
    • Re: Is HEAD broken for anybody else?, Giorgos Keramidas
      • Re: Is HEAD broken for anybody else?, Giorgos Keramidas
      • Re: Is HEAD broken for anybody else?, Bjoern A. Zeeb
      • Re: Is HEAD broken for anybody else?, Giorgos Keramidas
• Changes to IPFW start up scripts., Vulpes Velox
  • Re: Changes to IPFW start up scripts. [updated[, Vulpes Velox
• GELI question, Balgansuren Batsukh
  • Re: GELI question, Pawel Jakub Dawidek
• Re: It still here... panic: ufs_dirbad: bad dir, Matthew Dillon
  • Re: It still here... panic: ufs_dirbad: bad dir, Peter Jeremy
    • Re: It still here... panic: ufs_dirbad: bad dir, Matthew Dillon
      • Re: It still here... panic: ufs_dirbad: bad dir, Matthew Dillon
• LSI Trouble, Anton Nikiforov
  • Re: LSI Trouble, Brian K. White
• sio interrupt-level buffer overflows?, Goran Gajic
• CFT: wpa_supplicant key handling fix, Sam Leffler
• New RCorder: abi loaded too late, Xin LI
  • Re: New RCorder: abi loaded too late, Brooks Davis
    • Re: New RCorder: abi loaded too late, Doug Barton
      • Re: New RCorder: abi loaded too late, Brooks Davis
      • Re: New RCorder: abi loaded too late, Doug Barton
      • Re: New RCorder: abi loaded too late, Doug Barton
      • Re: New RCorder: abi loaded too late, Jason Evans
      • Re: New RCorder: abi loaded too late, Doug Barton
      • Re: New RCorder: abi loaded too late, Divacky Roman
      • Bad code in rcorder(8) (Was: Re: New RCorder: abi loaded too late), Doug Barton
      • Re: Bad code in rcorder(8) (Was: Re: New RCorder: abi loaded too late), Ulrich Spoerlein
      • Re: Bad code in rcorder(8) (Was: Re: New RCorder: abi loaded too late), Doug Barton
      • Re: Bad code in rcorder(8) (Was: Re: New RCorder: abi loaded too late), Divacky Roman
      • Message not available
      • Re: Bad code in rcorder(8) (Was: Re: New RCorder: abi loaded too late), Ulrich Spoerlein
• buildworld broken with NO_MODULES= and MODULES_WITH_WORLD=, Boris Samorodov
  • Re: buildworld broken with NO_MODULES= and MODULES_WITH_WORLD=, Ruslan Ermilov
    • Re: buildworld broken with NO_MODULES= and MODULES_WITH_WORLD=, Boris Samorodov
      • Re: buildworld broken with NO_MODULES= and MODULES_WITH_WORLD=, Ruslan Ermilov
      • Re: buildworld broken with NO_MODULES= and MODULES_WITH_WORLD=, Boris Samorodov
• panic at reboot (spin lock held too long), Thierry Herbelot
• hosts.allow default behaviour: IPv6 on its own lines, Dmitry Morozovsky
  • Re: hosts.allow default behaviour: IPv6 on its own lines, Hajimu UMEMOTO
  • Re: hosts.allow default behaviour: IPv6 on its own lines, Warner Losh
• reversed behavior with nsswitch.conf, Alexander Leidinger
  • Re: reversed behavior with nsswitch.conf, Foo
    • Re: reversed behavior with nsswitch.conf, Alexander Leidinger
      • Re: reversed behavior with nsswitch.conf, Joel Gunderson
      • Re: reversed behavior with nsswitch.conf, Alexander Leidinger
    • Re: reversed behavior with nsswitch.conf, Tim Dettloff
      • Re: reversed behavior with nsswitch.conf, Alexander Leidinger
• Cyrus-imap preformance share on fix, Benjamin D Adams
  • Re: Cyrus-imap preformance share on fix, Mike Jakubik
• dc no worky in -current, Daniel Eischen
  • Re: dc no worky in -current, Benzi Mizrahi
  • Re: dc no worky in -current, M. Warner Losh
• sshd/telnetd stops responding under load, Jiawei Ye
  • Re: sshd/telnetd stops responding under load, Peter Jeremy
• rwlock patch for bridge, Andrew Thompson
  • Re: rwlock patch for bridge, John Baldwin
    • Re: rwlock patch for bridge, Andrew Thompson
      • Re: rwlock patch for bridge, John Baldwin
• buildworld problem, Vincent Blondel
  • Re: buildworld problem, Joseph Koshy
    • Re: buildworld problem, Vincent Blondel
      • Re: buildworld problem, Joseph Koshy
      • Re: buildworld problem, Vincent Blondel
      • Re: buildworld problem, Joseph Koshy
      • Re: buildworld problem, Vincent Blondel
  • Re: buildworld problem, Brian Candler
• Extended Attributes API, Geoffrey Giesemann
  • Re: Extended Attributes API, Michael Reifenberger
    • Re: Extended Attributes API, Geoffrey Giesemann
      • Re: Extended Attributes API, Harti Brandt
      • Re: Extended Attributes API, Joerg Schilling
      • Re: Extended Attributes API, Jason Evans
• IMAP problem I found on another mailing list, Benjamin D Adams
• Virtual memory consumption (both user and kernel) in modern CURRENT, Dmitry Pryanishnikov
  • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, David Xu
    • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Brian Candler
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Giorgos Keramidas
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Mike Jakubik
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Kris Kennaway
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Mike Jakubik
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Jason Evans
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Mike Jakubik
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Jason Evans
      • Re: Virtual memory consumption (both user and kernel) inmodern CURRENT, Brian K. White
      • Re: Virtual memory consumption (both user and kernel) inmodern CURRENT, David Leimbach
    • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Dmitry Pryanishnikov
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Kris Kennaway
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, David Xu
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Dmitry Pryanishnikov
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Jason Evans
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Brian Candler
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Jason Evans
  • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Tarasov Alexey
  • <Possible follow-ups>
  • Virtual memory consumption (both user and kernel) in modern CURRENT, Peter Fraser
    • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Robert Watson
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Peter Fraser
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Robert Watson
    • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Jonathan Noack
    • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Mark Kirkwood
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Mike Jakubik
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Mark Kirkwood
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Mike Jakubik
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Jason Evans
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Poul-Henning Kamp
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, Jason Evans
      • Re: Virtual memory consumption (both user and kernel) in modern CURRENT, John Baldwin
• Buildworld broken on amd64, Steve Kargl
  • Re: Buildworld broken on amd64, Steve Kargl
  • Re: Buildworld broken on amd64, Doug Ambrisko
• panic: Trying sleep, but thread marked as sleeping prohibited, Christian Brueffer
  • Re: panic: Trying sleep, but thread marked as sleeping prohibited, Mark Tinguely
    • Re: panic: Trying sleep, but thread marked as sleeping prohibited, Suleiman Souhlal
  • Re: panic: Trying sleep, but thread marked as sleeping prohibited, Ian Dowse
    • Re: panic: Trying sleep, but thread marked as sleeping prohibited, Christian Brueffer
    • Re: panic: Trying sleep, but thread marked as sleeping prohibited, Christian Brueffer
• Regarding the diagnostic utility for the PCI bus, karthy shanmugavel
• memtest - an idea, Vladimir Konrad
  • Re: memtest - an idea, Peter Jeremy
  • Re: memtest - an idea, Holger Kipp
• options for centralized 'passwd' database for a diskless lab ?, Luigi Rizzo
  • Re: options for centralized 'passwd' database for a diskless lab ?, Chuck Swiger
  • Re: options for centralized 'passwd' database for a diskless lab ?, Stefan Bethke
  • <Possible follow-ups>
  • Re: options for centralized 'passwd' database for a diskless lab ?, Danny Braniss
• Error in make buildkernel from todays -current, Tarc
  • Re: Error in make buildkernel from todays -current, Ruslan Ermilov
• (idle) USB generates interrupts as fast as they can be serviced, Ian FREISLICH
• [head tinderbox] failure on sparc64/sparc64, FreeBSD Tinderbox
  • <Possible follow-ups>
  • [head tinderbox] failure on sparc64/sparc64, FreeBSD Tinderbox
  • [head tinderbox] failure on sparc64/sparc64, FreeBSD Tinderbox
  • [head tinderbox] failure on sparc64/sparc64, FreeBSD Tinderbox
• Error in make buildworld from todays -current, Patrick Bowen
  • Re: Error in make buildworld from todays -current, Doug Barton
• Re: bsd-airtools, Patrick Bowen
  • Re: bsd-airtools, Sam Leffler
    • Re: bsd-airtools, Sean Chittenden
• HEADSUP: new ath+hal, Sam Leffler
  • Re: HEADSUP: new ath+hal, Patrick Bowen
    • Re: HEADSUP: new ath+hal, Marcin Jessa
  • Re: HEADSUP: new ath+hal, Yamamoto Shigeru
    • Re: HEADSUP: new ath+hal, Sam Leffler
      • Re: HEADSUP: new ath+hal, Yamamoto Shigeru
      • Re: HEADSUP: new ath+hal, Michal Mertl
      • Re: HEADSUP: new ath+hal, Sam Leffler
      • Re: HEADSUP: new ath+hal, Sam Leffler
      • Re: HEADSUP: new ath+hal, Yamamoto Shigeru
      • Re: HEADSUP: new ath+hal, Sam Leffler
      • Re: HEADSUP: new ath+hal [patch], Sam Leffler
      • Re: HEADSUP: new ath+hal, Sam Leffler
• Re: Malloc bugs exhibited in ports/mail/dovecot, Robin Breathe
• insta-panic in softclock() -> acctwatch(), Giorgos Keramidas
  • Re: insta-panic in softclock() -> acctwatch(), Gleb Smirnoff
    • Re: insta-panic in softclock() -> acctwatch(), Giorgos Keramidas
• Radio Streaming, Vincent Blondel
  • Re: Radio Streaming, Ulrich Spoerlein
• Wall broken with sysutils/screen, Ceri Davies
• calcru: runtime went backwards, Yuriy Tsibizov
  • Re: calcru: runtime went backwards, Yuriy Tsibizov
    • Re: calcru: runtime went backwards, Kris Kennaway
      • Re: calcru: runtime went backwards, Niki Denev
  • Re: calcru: runtime went backwards, Poul-Henning Kamp
    • Re: calcru: runtime went backwards, Yuriy Tsibizov
      • Re: calcru: runtime went backwards, Poul-Henning Kamp
      • Re: calcru: runtime went backwards, Yuriy Tsibizov
      • Re: calcru: runtime went backwards, Poul-Henning Kamp
      • Re: calcru: runtime went backwards, Jiawei Ye
      • Re: calcru: runtime went backwards, Giorgos Keramidas
      • Re: calcru: runtime went backwards, Poul-Henning Kamp
      • Re: calcru: runtime went backwards, Kris Kennaway
  • <Possible follow-ups>
  • calcru: runtime went backwards, David Xu
    • Re: calcru: runtime went backwards, Kazuaki Oda
      • Re: calcru: runtime went backwards, David Xu
      • Re: calcru: runtime went backwards, Kazuaki Oda
• Atheros and new hal, gusmao
  • <Possible follow-ups>
  • Re: Atheros and new hal, Dillon Kass
• Error building acpi_wakecode.S, James Bowman
• A problem on IBM Netfinity 5000, FreeBSDer China
  • Re: A problem on IBM Netfinity 5000, Brian Candler
• GELI improvements., Pawel Jakub Dawidek
• Re: acpica memory leak?, Morten Rodal
  • Re: acpica memory leak?, Jung-uk Kim
• -current is sluggish, Maksim Yevmenkin
  • Re: -current is sluggish, Andrew R. Reiter
  • Re: -current is sluggish, Max Laier
    • Re: -current is sluggish, Maksim Yevmenkin
    • Re: -current is sluggish, Krzysztof Kowalik
      • Re: -current is sluggish, Jonathan Noack
      • Re: -current is sluggish, Krzysztof Kowalik
      • Re: -current is sluggish, Giorgos Keramidas
      • Re: -current is sluggish, Jonathan Noack
      • Re: -current is sluggish, Giorgos Keramidas
  • Re: -current is sluggish, Maksim Yevmenkin
    • Re: -current is sluggish, Yar Tikhiy
      • Re: -current is sluggish, Kevin Oberman
      • Re: -current is sluggish, Kris Kennaway
• Portsnap support on CURRENT, Paul Mather
  • Re: Portsnap support on CURRENT, Scott Robbins
  • Re: Portsnap support on CURRENT, Freddie Cash
    • Re: Portsnap support on CURRENT, Kris Kennaway
      • Re: Portsnap support on CURRENT, Colin Percival
    • Re: Portsnap support on CURRENT, Martin Wilke
• [jakub@redhat.com:Linking against libpthread via -pthread?, Steve Kargl
  • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Dan Nelson
    • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Steve Kargl
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Dan Nelson
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Alexander Kabaev
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Steve Kargl
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Daniel Eischen
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Steve Kargl
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Daniel Eischen
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Alexander Kabaev
      • Re: [jakub@redhat.com:Linking against libpthread via -pthread?, Daniel Eischen
• hesiod.h problem while upgrading to current, Michael Jejer
• [panic] Fatal trap 12: page fault while in kernel mode, Daniel Gerzo
• Bad system call (core dumped), Bachilo Dmitry
  • Re: Bad system call (core dumped), Kris Kennaway
  • Re: Bad system call (core dumped), Fernan Aguero
    • Re: Bad system call (core dumped), Bachilo Dmitry
      • Re: Bad system call (core dumped), Joseph Koshy
      • Re: Bad system call (core dumped), Bachilo Dmitry
      • Re: Bad system call (core dumped), Joseph Koshy
      • Re: Bad system call (core dumped), Bachilo Dmitry
      • Re: Bad system call (core dumped), David Xu
      • Re: Bad system call (core dumped), Joseph Koshy
      • Re: Bad system call (core dumped), David Xu
      • Re: Bad system call (core dumped), Joseph Koshy
      • Re: Bad system call (core dumped), Robert Watson
• [TEST/REVIEW] cpu time accounting patch, step 2, Poul-Henning Kamp
  • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Poul-Henning Kamp
  • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Mike Jakubik
    • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Poul-Henning Kamp
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Kris Kennaway
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Kris Kennaway
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Anish Mistry
  • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Andrew Gallatin
    • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Andrew Gallatin
    • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Poul-Henning Kamp
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Andrew Gallatin
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Poul-Henning Kamp
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Julian Elischer
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Robert Watson
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Andrew Gallatin
      • Re: [TEST/REVIEW] cpu time accounting patch, step 2, Robert Watson
• Feature request for IPFW, Erik Nørgaard
• FreeBSD Port to UltraSparc T1 "Niagara", Ricardo A. Reis
  • Re: FreeBSD Port to UltraSparc T1 "Niagara", Joao Barros
  • Re: FreeBSD Port to UltraSparc T1 "Niagara", Doug White
• FreeBSD showing version number upon login, Alex
  • Re: FreeBSD showing version number upon login, Kris Kennaway
    • Re: FreeBSD showing version number upon login, Andrew R. Reiter
      • Re: FreeBSD showing version number upon login, Chris
      • Re: FreeBSD showing version number upon login, Kris Kennaway
  • Re: FreeBSD showing version number upon login, Marcin Jessa
    • Re: FreeBSD showing version number upon login, alex
      • Re: FreeBSD showing version number upon login, Marcin Jessa
      • Re: FreeBSD showing version number upon login, Frank Altpeter
      • Re: FreeBSD showing version number upon login, Poul-Henning Kamp
      • Re: FreeBSD showing version number upon login, Marcin Jessa
      • Re: FreeBSD showing version number upon login, Frank Altpeter
      • Re: FreeBSD showing version number upon login, Kurt Jaeger
      • Message not available
      • Re: FreeBSD showing version number upon login, alex
      • Re: FreeBSD showing version number upon login, Kris Kennaway
      • Re: FreeBSD showing version number upon login, Matthew D. Fuller
      • Re: FreeBSD showing version number upon login, alex
  • RE: FreeBSD showing version number upon login, Darren Pilgrim
  • Re: FreeBSD showing version number upon login, Brian Candler
    • Re: FreeBSD showing version number upon login, Brian Candler
• semi-interesting panic when rebooting, Matthew Jacob
  • Re: semi-interesting panic when rebooting, John Baldwin
• Re: cvs commit: src/sys/dev/em if_em.c if_em.h, Harald Schmalzbauer
  • Re: cvs commit: src/sys/dev/em if_em.c if_em.h, Gleb Smirnoff
• Panic In mi_switch+0x7e, Cy Schubert
  • Re: Panic In mi_switch+0x7e, John Baldwin
• Re: Which signal occurs due to a page protection violation?, Sam Lawrance
  • Re: Which signal occurs due to a page protection violation?, David Xu
• memguard monitoring of more than 1 memory_type?, Steve Kargl
  • Re: memguard monitoring of more than 1 memory_type?, Yar Tikhiy
    • Re: memguard monitoring of more than 1 memory_type?, Steve Kargl
      • Re: memguard monitoring of more than 1 memory_type?, Pawel Jakub Dawidek
      • Re: memguard monitoring of more than 1 memory_type?, Peter Jeremy
      • Re: memguard monitoring of more than 1 memory_type?, Pawel Jakub Dawidek
• panic: mutex Giant not owned at sys/kern/vfs_subr.c:2029, Cy Schubert
  • Re: panic: mutex Giant not owned at sys/kern/vfs_subr.c:2029, Gleb Smirnoff
• ath patch+hal for test, Sam Leffler
  • Re: ath patch+hal for test, Ryan R
    • Re: ath patch+hal for test, Ryan R
      • Re: ath patch+hal for test, Patrick Bowen
    • Re: ath patch+hal for test, Beech Rintoul
• Re: 7.0-CURRENT Hang, Cy Schubert
  • <Possible follow-ups>
  • Re: 7.0-CURRENT Hang, Cy Schubert
    • Re: 7.0-CURRENT Hang, Yar Tikhiy
      • Re: 7.0-CURRENT Hang, Cy Schubert
      • Re: 7.0-CURRENT Hang, Yar Tikhiy
      • Re: 7.0-CURRENT Hang, Cy Schubert
      • Re: 7.0-CURRENT Hang, Yar Tikhiy
      • Re: 7.0-CURRENT Hang, Watanabe Kazuhiro
      • Re: 7.0-CURRENT Hang, Cy Schubert
      • Re: 7.0-CURRENT Hang, Yar Tikhiy
      • Re: 7.0-CURRENT Hang, Cy Schubert
• [ATA] [patch] crashes, deadlock, memory leaks, . plus LSI RAID write support, Garry Belka
  • Re: [ATA] [patch] crashes, deadlock, memory leaks, . plus LSI RAID write support, Søren Schmidt
• audit group, Randy Bush
  • Re: audit group, Kris Kennaway
    • Re: audit group, Randy Bush
    • Re: audit group, Doug Barton
• AnyDATA USB Modem, Jan Dušátko
• snap10 works, snap12 doesn't, Michael W. Lucas
  • Re: snap10 works, snap12 doesn't, Michael W. Lucas
  • <Possible follow-ups>
  • Re:Re: snap10 works, snap12 doesn't, Michael Jejer
• Parallel buildkernel (still) broken?, Ian FREISLICH
  • Re: Parallel buildkernel (still) broken?, Stefan Ehmann
    • Re: Parallel buildkernel (still) broken?, Ruslan Ermilov
      • Re: Parallel buildkernel (still) broken?, Ian FREISLICH
      • Re: Parallel buildkernel (still) broken?, Stefan Ehmann
      • Re: Parallel buildkernel (still) broken?, Ruslan Ermilov
      • Re: Parallel buildkernel (still) broken?, Stefan Ehmann
      • Re: Parallel buildkernel (still) broken?, Ian FREISLICH
  • Re: Parallel buildkernel (still) broken?, M. Warner Losh
  • Re: Parallel buildkernel (still) broken?, Ruslan Ermilov
• Cannot boot the 7-current's GENERIC kernel on some old PCs (Pentium/P54C, DX4ODP), Watanabe Kazuhiro
  • Re: Cannot boot the 7-current's GENERIC kernel on some old PCs (Pentium/P54C, DX4ODP), Alexander Leidinger
• Peter's talk on amd64 audio online, Julian Elischer
  • Re: Peter's talk on amd64 audio online, Marcin Jessa
    • Re: Peter's talk on amd64 audio online, Colin Percival
      • Re: Peter's talk on amd64 audio online, Marcin Jessa
    • Re: Peter's talk on amd64 audio online, Alistair Sutton
      • Re: Peter's talk on amd64 audio online, Marcin Jessa
      • Re: Peter's talk on amd64 audio online, Mike Jakubik
      • Re: Peter's talk on amd64 audio online, Julian Elischer
      • Re: Peter's talk on amd64 audio online, Mike Jakubik
      • Re: Peter's talk on amd64 audio online, Doug Poland
  • Re: Peter's talk on amd64 audio online, Panagiotis Astithas
    • Re: Peter's talk on amd64 audio online, Marcin Jessa
    • Re: Peter's talk on amd64 audio online, Giorgos Keramidas
    • Re: Peter's talk on amd64 audio online, Julian Elischer
• unprivileged users are able to kill certain jailed processes, Björn König
  • Re: unprivileged users are able to kill certain jailed processes, Björn König
  • Re: unprivileged users are able to kill certain jailed processes, Robert Watson
    • Re: unprivileged users are able to kill certain jailed processes, Björn König
      • Re: unprivileged users are able to kill certain jailed processes, Joseph Koshy
  • Re: unprivileged users are able to kill certain jailed processes, Andre Oppermann
    • Re: unprivileged users are able to kill certain jailed processes, Björn König
      • Re: unprivileged users are able to kill certain jailed processes, Chad Leigh -- Shire.Net LLC
      • Re: unprivileged users are able to kill certain jailed processes, Julian Elischer
      • Re: unprivileged users are able to kill certain jailed processes, Chad Leigh -- Shire.Net LLC
• panic: mutex Giant not owned at sys/kern/vfs_subr.c: 2029, Doug Barton
  • Re: panic: mutex Giant not owned at sys/kern/vfs_subr.c: 2029, Gleb Smirnoff
    • Re: panic: mutex Giant not owned at sys/kern/vfs_subr.c: 2029, Doug Barton
• patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Daichi GOTO
  • Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Dario Freni
  • Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Danny Braniss
    • Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Daichi GOTO
      • Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Dario Freni
      • Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Daichi GOTO
      • Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Dario Freni
      • Re: patchset-7 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Daichi GOTO
      • patchset-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Daichi GOTO
      • Re: patchset-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Dario Freni
      • Re: patchset-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Cy Schubert
      • Re: patchset-8 release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Dario Freni
      • patchset-8-fix1 for 6.x release (Re: [unionfs][patch] improvements of the unionfs - Problem Report, kern/91010), Daichi GOTO
• panic: Giant not owned in vfs_subr.c:2029, Ruslan Ermilov
• jail leak, Kris Kennaway
  • Re: jail leak, Chad Leigh -- Shire.Net LLC
    • Re: jail leak, Kris Kennaway
  • Re: jail leak, Bjoern A. Zeeb
  • Re: jail leak, Stefan Bethke
• [head tinderbox] failure on amd64/amd64, FreeBSD Tinderbox
  • Re: [head tinderbox] failure on amd64/amd64, Max Laier
    • Re: [head tinderbox] failure on amd64/amd64, Robert Watson
  • <Possible follow-ups>
  • [head tinderbox] failure on amd64/amd64, FreeBSD Tinderbox
  • [head tinderbox] failure on amd64/amd64, FreeBSD Tinderbox
  • [head tinderbox] failure on amd64/amd64, FreeBSD Tinderbox
  • [head tinderbox] failure on amd64/amd64, FreeBSD Tinderbox
• machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
  • Re: machdep.cpu_idle_hlt and SMP perf?, Kris Kennaway
    • Re: machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
    • Re: machdep.cpu_idle_hlt and SMP perf?, Marcin Jessa
      • Re: machdep.cpu_idle_hlt and SMP perf?, Kris Kennaway
      • Re: machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
  • Re: machdep.cpu_idle_hlt and SMP perf?, David Xu
  • Re: machdep.cpu_idle_hlt and SMP perf?, Ivan Voras
    • Re: machdep.cpu_idle_hlt and SMP perf?, M. Warner Losh
      • Re: machdep.cpu_idle_hlt and SMP perf?, Yar Tikhiy
  • Re: machdep.cpu_idle_hlt and SMP perf?, Andre Oppermann
    • Re: machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
      • Re: machdep.cpu_idle_hlt and SMP perf?, John Baldwin
      • Re: machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
      • Re: machdep.cpu_idle_hlt and SMP perf?, John Baldwin
      • Re: machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
      • Re: machdep.cpu_idle_hlt and SMP perf?, John Baldwin
      • Re: machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
      • Re: machdep.cpu_idle_hlt and SMP perf?, John Baldwin
      • Re: machdep.cpu_idle_hlt and SMP perf?, Andrew Gallatin
      • Re: machdep.cpu_idle_hlt and SMP perf?, John Baldwin
  • <Possible follow-ups>
  • RE: machdep.cpu_idle_hlt and SMP perf?, Daniel Eriksson
    • Message not available
      • RE: machdep.cpu_idle_hlt and SMP perf?, Mike Tancsa
• [head tinderbox] failure on i386/pc98, FreeBSD Tinderbox
  • <Possible follow-ups>
  • [head tinderbox] failure on i386/pc98, FreeBSD Tinderbox
  • [head tinderbox] failure on i386/pc98, FreeBSD Tinderbox
  • [head tinderbox] failure on i386/pc98, FreeBSD Tinderbox
• [head tinderbox] failure on i386/i386, FreeBSD Tinderbox
  • <Possible follow-ups>
  • [head tinderbox] failure on i386/i386, FreeBSD Tinderbox
  • [head tinderbox] failure on i386/i386, FreeBSD Tinderbox
  • [head tinderbox] failure on i386/i386, FreeBSD Tinderbox
  • [head tinderbox] failure on i386/i386, FreeBSD Tinderbox
• buglets with pts - with patch, Michal Mertl
  • Re: buglets with pts - with patch, Michal Mertl
    • Re: buglets with pts - with patch, Michal Mertl
• mapping "random" physical memory into kernel, Andrew Gallatin
  • Re: mapping "random" physical memory into kernel, Scott Long
    • Re: mapping "random" physical memory into kernel, Andrew Gallatin
      • Re: mapping "random" physical memory into kernel, Scott Long
• [head tinderbox] failure on alpha/alpha, FreeBSD Tinderbox
  • <Possible follow-ups>
  • [head tinderbox] failure on alpha/alpha, FreeBSD Tinderbox
  • [head tinderbox] failure on alpha/alpha, FreeBSD Tinderbox
  • [head tinderbox] failure on alpha/alpha, FreeBSD Tinderbox
  • [head tinderbox] failure on alpha/alpha, FreeBSD Tinderbox
  • [head tinderbox] failure on alpha/alpha, FreeBSD Tinderbox
• hwpmc & kernel modules?, Andrew Gallatin
  • Re: hwpmc & kernel modules?, Joseph Koshy
• unstable kernels in -current right now?, Matthew Jacob
  • Re: unstable kernels in -current right now?, Jeff Roberson
• HEADSUP: New pts code triggers panics on amd64 systems., Steve Kargl
  • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
    • Re: HEADSUP: New pts code triggers panics on amd64 systems., Gary Jennejohn
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Gary Jennejohn
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
    • Re: HEADSUP: New pts code triggers panics on amd64 systems., Robert Watson
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Gary Jennejohn
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Steve Kargl
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
      • Re: HEADSUP: New pts code triggers panics on amd64 systems., Giorgos Keramidas
• HEADS UP: Audit integration into CVS in progress, some tree disruption, Robert Watson
  • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Kövesdán Gábor
    • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Robert Watson
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Mike Jakubik
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Robert Watson
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Kris Kennaway
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Robert Watson
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Kris Kennaway
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Doug Barton
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Mike Jakubik
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Robert Watson
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Tom Rhodes
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Mike Jakubik
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Peter Jeremy
    • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Julian Elischer
      • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Robert Watson
  • Re: HEADS UP: Audit integration into CVS in progress, some tree disruption, Robert Watson
• subdisk6: detached --> Fatal trap 9, Jason Evans
  • Re: subdisk6: detached --> Fatal trap 9, Jason Evans
• For the love of God, is it even possible to make the Atheros ath.patch & updated HAL actually work?, Ryan R
  • Re: For the love of God, is it even possible to make the Atheros ath.patch & updated HAL actually work?, Andrew Atrens
  • RE: For the love of God, is it even possible to make the Atheros ath.patch & updated HALactually work?, Daniel Dvorak
    • Re: For the love of God, is it even possible to make the Atheros ath.patch & updated HALactually work?, Sam Leffler
  • Re: For the love of God, is it even possible to make the Atheros ath.patch & updated HAL actually work?, Guy Brand
• Memory modified panic -- was: Re: cvs commit: src/sys/kern kern_malloc.c, Steve Kargl
• em(4) stops forwarding, Michal Mertl
  • Re: em(4) stops forwarding, Scott Long
    • Re: em(4) stops forwarding, Michal Mertl
      • Re: em(4) stops forwarding, Scott Long
      • Re: em(4) stops forwarding, Yamamoto Shigeru
      • Re: em(4) stops forwarding, Fabian Keil
      • Re: em(4) stops forwarding, Michal Mertl
      • Re: em(4) stops forwarding, Scott Long
      • Re: em(4) stops forwarding, Julian Elischer
      • Re: em(4) stops forwarding, Jack Vogel
      • Re: em(4) stops forwarding, Scott Long
      • Re: em(4) stops forwarding, Michal Mertl
  • <Possible follow-ups>
  • Re: em(4) stops forwarding, MonkeyBrains
• Re: xorg 6.9.0 mem leak, David Scheidt
  • Re: xorg 6.9.0 mem leak, Randy Bush
    • Re: xorg 6.9.0 mem leak, Kris Kennaway
      • Re: xorg 6.9.0 mem leak, Gary Palmer
      • Re: xorg 6.9.0 mem leak, Jung-uk Kim
      • Re: xorg 6.9.0 mem leak, Joe Marcus Clarke
      • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Alexander Leidinger
  • <Possible follow-ups>
  • Re: xorg 6.9.0 mem leak, Jason Evans
    • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Jason Evans
    • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Jason Evans
    • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Matt Reimer
      • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Josh Carroll
      • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Freddie Cash
      • Re: xorg 6.9.0 mem leak, Randy Bush
      • Re: xorg 6.9.0 mem leak, Thomas Gellekum
  • Re: xorg 6.9.0 mem leak, Randy Bush
• nextboot (was Re: boot block differences between 4.x and 6.x ?), Oliver Fromme
  • Re: nextboot (was Re: boot block differences between 4.x and 6.x ?), John Baldwin
    • Re: nextboot (was Re: boot block differences between 4.x and 6.x ?), Julian Elischer
      • Re: nextboot (was Re: boot block differences between 4.x and 6.x ?), Scott Long
      • Re: nextboot (was Re: boot block differences between 4.x and 6.x ?), John Baldwin
      • Re: nextboot (was Re: boot block differences between 4.x and 6.x ?), Julian Elischer
      • Re: nextboot (was Re: boot block differences between 4.x and 6.x ?), John Baldwin
  • Re: nextboot (was Re: boot block differences between 4.x and 6.x ?), Julian Elischer
• Re: boot problem with atapicam, Thomas Quinot
  • Re: boot problem with atapicam, Michiel Boland
    • Re: boot problem with atapicam, Thomas Quinot
• Re: Patch to fix i915 drm with vgapci changes, Stefan Ehmann
  • Re: Patch to fix i915 drm with vgapci changes, John Baldwin
• Newly developed mailling list search engine needs more testing, Choy Kho Yee
• Re: KDE 3.5.0 seems much chubbier than 3.4.2, Daniel O'Connor
  • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Jason Evans
    • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Daniel O'Connor
      • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Jason Evans
      • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Daniel O'Connor
  • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Randy Bush
    • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Daniel O'Connor
      • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Peter Jeremy
      • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Daniel O'Connor
      • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Peter Jeremy
      • Re: KDE 3.5.0 seems much chubbier than 3.4.2, Daniel O'Connor
• Re: panic: Memory modified after free, Steve Kargl
  • Re: panic: Memory modified after free, Steve Kargl
    • Re: panic: Memory modified after free, Giorgos Keramidas
    • Re: panic: Memory modified after free, Doug White
      • Re: panic: Memory modified after free, Steve Kargl
      • Re: panic: Memory modified after free, Matthew D. Fuller
      • Re: panic: Memory modified after free, Doug White
  • <Possible follow-ups>
  • Re: panic: Memory modified after free, Pawel Jakub Dawidek
• Re: [RFC] what do we do with picobsd ?, Dario Freni
  • <Possible follow-ups>
  • Re: [RFC] what do we do with picobsd ?, Peter Jeremy
  • Re: [RFC] what do we do with picobsd ?, Dario Freni
    • Re: [RFC] what do we do with picobsd ?, Julian Elischer
      • Re: [RFC] what do we do with picobsd ?, Julian Elischer
      • Re: [RFC] what do we do with picobsd ?, Dario Freni
      • Re: [RFC] what do we do with picobsd ?, Dario Freni
• Re: MFC of bump in libcom_err.so another mistake?, Robert Watson
  • Re: MFC of bump in libcom_err.so another mistake?, Sean McNeil
    • Re: MFC of bump in libcom_err.so another mistake?, Robert Watson
    • Re: MFC of bump in libcom_err.so another mistake?, Daniel Eischen
      • Re: MFC of bump in libcom_err.so another mistake?, Sean McNeil
      • Re: MFC of bump in libcom_err.so another mistake?, Kris Kennaway
      • Re: MFC of bump in libcom_err.so another mistake?, Daniel Eischen
      • Re: MFC of bump in libcom_err.so another mistake?, Daniel Eischen
      • Re: MFC of bump in libcom_err.so another mistake?, Robert Watson
      • Re: MFC of bump in libcom_err.so another mistake?, Doug Barton
      • Message not available
      • Re: MFC of bump in libcom_err.so another mistake?, Robert Watson
      • Message not available
      • Re: MFC of bump in libcom_err.so another mistake?, Doug Barton
    • Re: MFC of bump in libcom_err.so another mistake?, Panagiotis Astithas
  • <Possible follow-ups>
  • Re: MFC of bump in libcom_err.so another mistake?, Doug Barton
• ServerWorks HT1000 Chipset SATA support, Mike Jakubik
  • Re: ServerWorks HT1000 Chipset SATA support, Søren Schmidt
    • Re: ServerWorks HT1000 Chipset SATA support, Mike Jakubik

• Security
• UNIX
• Linux
• Coding
• Usenet

• Mailing-Lists
• Newsgroups
• About
• Privacy
• Search
• Imprint