tech-kern by thread

• Date Index
• Date Index (newest page)
• Old Index

• Scsipi guru needed..., Anders Magnusson
  • Re: Scsipi guru needed..., Manuel Bouyer
    • Re: Scsipi guru needed..., Anders Magnusson
      • Re: Scsipi guru needed..., Thor Lancelot Simon
      • Re: Scsipi guru needed..., Reinoud Zandijk
      • Re: Scsipi guru needed..., Manuel Bouyer
      • Re: Scsipi guru needed..., Michael L. Hitch
      • Re: Scsipi guru needed..., Michael L. Hitch
  • Re: Scsipi guru needed..., Michael L. Hitch
    • Re: Scsipi guru needed..., Anders Magnusson
• Atheros HAL opensourced, Arnaud Lacombe
  • Re: Atheros HAL opensourced, Quentin Garnier
    • Re: Atheros HAL opensourced, Arnaud Lacombe
      • Re: Atheros HAL opensourced, Arnaud Lacombe
• Fixing tap(4) behaviour, Arnaud Lacombe
  • Re: Fixing tap(4) behaviour, Quentin Garnier
    • Re: Fixing tap(4) behaviour, Manuel Bouyer
    • Re: Fixing tap(4) behaviour, Arnaud Lacombe
      • Re: Fixing tap(4) behaviour, Quentin Garnier
      • Re: Fixing tap(4) behaviour, Christos Zoulas
      • Re: Fixing tap(4) behaviour, Arnaud Lacombe
      • Re: Fixing tap(4) behaviour, Quentin Garnier
• Re: Module problem on amd64 (fwd), Paul Goyette
  • Re: Module problem on amd64 (fwd), der Mouse
    • Re: Module problem on amd64 (fwd), Paul Goyette
      • Re: Module problem on amd64 (fwd), Paul Goyette
• virtual kernels, syscall routing, etc., Antti Kantee
  • Re: virtual kernels, syscall routing, etc., Andrew Doran
    • Re: virtual kernels, syscall routing, etc., Antti Kantee
      • Re: virtual kernels, syscall routing, etc., Andrew Doran
      • Re: virtual kernels, syscall routing, etc., Antti Kantee
  • virtualized nfsd (Re: virtual kernels, syscall rou, Antti Kantee
    • Re: virtualized nfsd (Re: virtual kernels, syscall, der Mouse
      • Re: virtualized nfsd (Re: virtual kernels, syscall, Matthias Scheler
      • Re: virtualized nfsd (Re: virtual kernels, syscall, Antti Kantee
      • Re: virtualized nfsd (Re: virtual kernels, syscall, der Mouse
      • Re: virtualized nfsd (Re: virtual kernels, syscall, matthew sporleder
      • Re: virtualized nfsd (Re: virtual kernels, syscall, Antti Kantee
    • Re: virtualized nfsd (Re: virtual kernels, syscall, Antti Kantee
• Re: panic: softdep_deallocate_dependencies: unreco, Edgar Fuß
  • Re: panic: softdep_deallocate_dependencies: unreco, Greg Oster
    • Re: panic: softdep_deallocate_dependencies: unreco, Andrew Doran
      • Re: panic: softdep_deallocate_dependencies: unreco, Greg Oster
      • Re: panic: softdep_deallocate_dependencies: unreco, Edgar Fuß
• re(4) patch curing livelocks, Dennis den Brok
• Using modules for non-i386 GENERIC kernels, Paul Goyette
• Re: panic: softdep_deallocate_dependencies: unreco, Brian Buhrow
  • Re: panic: softdep_deallocate_dependencies: unreco, Greg Oster
• sigaction(2) broken in -current, Matthias Drochner
  • Re: sigaction(2) broken in -current, Mikko Rapeli
  • Re: sigaction(2) broken in -current, Andrew Doran
    • Re: sigaction(2) broken in -current, Matthias Drochner
• Equivalent of the system call sendfile, kamel derouiche
  • Re: Equivalent of the system call sendfile, Ignatios Souvatzis
    • Re: Equivalent of the system call sendfile, David Huang
    • Re: Equivalent of the system call sendfile, Wouter Klouwen
      • Re: Equivalent of the system call sendfile, Ignatios Souvatzis
      • Re: Equivalent of the system call sendfile, kamel derouiche
      • Re: Equivalent of the system call sendfile, Wouter Klouwen
      • Re: Equivalent of the system call sendfile, David Laight
      • Re: Equivalent of the system call sendfile, Thor Lancelot Simon
      • Re: Equivalent of the system call sendfile, Matthias Scheler
      • Re: Equivalent of the system call sendfile, Jason Thorpe
    • Re: Equivalent of the system call sendfile, kamel derouiche
• panic: softdep_deallocate_dependencies: unrecovere, Edgar Fuß
  • Re: panic: softdep_deallocate_dependencies: unreco, Greg Oster
  • saving RAIDframe parity accross a panic, Edgar Fuß
    • Re: saving RAIDframe parity accross a panic, Greg Oster
      • Re: saving RAIDframe parity accross a panic, Edgar Fuß
      • Re: saving RAIDframe parity accross a panic, Greg Oster
      • Re: saving RAIDframe parity accross a panic, Edgar Fuß
      • Re: saving RAIDframe parity accross a panic, Greg Oster
      • Re: saving RAIDframe parity accross a panic, der Mouse
      • replacing a soon-to-fail RAID component on the fly, Edgar Fuß
      • Re: replacing a soon-to-fail RAID component on the, der Mouse
      • Re: saving RAIDframe parity accross a panic, Edgar Fuß
      • Re: saving RAIDframe parity accross a panic, Geert Hendrickx
      • Re: saving RAIDframe parity accross a panic, Thor Lancelot Simon
      • Re: saving RAIDframe parity accross a panic, Greg Oster
  • Re: panic: softdep_deallocate_dependencies: unreco, Andrew Doran
    • Re: panic: softdep_deallocate_dependencies: unreco, Edgar Fuß
  • Again: panic: softdep_deallocate_dependencies: unr, Edgar Fuß
    • Re: Again: panic: softdep_deallocate_dependencies:, Greg Oster
• Analyzing a 4.0/amd64 panic, Edgar Fuß
  • Re: Analyzing a 4.0/amd64 panic, David Laight
    • Re: Analyzing a 4.0/amd64 panic, Edgar Fuß
      • Re: Analyzing a 4.0/amd64 panic, David Laight
      • Re: Analyzing a 4.0/amd64 panic, Edgar Fuß
  • Re: Analyzing a 4.0/amd64 panic, Andrew Doran
    • Re: Analyzing a 4.0/amd64 panic, Edgar Fuß
• a small cgd(4) hiccup?, Nino Dehne
• patch to support >16 bit g/uids on ext2fs, matthew green
  • Re: patch to support >16 bit g/uids on ext2fs, Izumi Tsutsui
    • re: patch to support >16 bit g/uids on ext2fs, matthew green
      • Re: patch to support >16 bit g/uids on ext2fs, Izumi Tsutsui
      • re: patch to support >16 bit g/uids on ext2fs, matthew green
      • Re: patch to support >16 bit g/uids on ext2fs, Izumi Tsutsui
      • re: patch to support >16 bit g/uids on ext2fs, matthew green
      • Re: patch to support >16 bit g/uids on ext2fs, Izumi Tsutsui
• Changes for the WAPBL replay format, Joerg Sonnenberger
• Lockups and other trouble using large disks, raid(, Nino Dehne
  • Re: Lockups and other trouble using large disks, r, Thor Lancelot Simon
    • Re: Lockups and other trouble using large disks, r, Nino Dehne
      • Re: Lockups and other trouble using large disks, r, Thor Lancelot Simon
  • Re: Lockups and other trouble using large disks, r, Manuel Bouyer
    • Re: Lockups and other trouble using large disks, r, Nino Dehne
• partitioning >2TB?, der Mouse
  • Re: partitioning >2TB?, Joerg Sonnenberger
    • Re: partitioning >2TB?, der Mouse
      • Re: partitioning >2TB?, Joerg Sonnenberger
      • Re: partitioning >2TB?, der Mouse
      • Re: partitioning >2TB?, Joerg Sonnenberger
      • Re: partitioning >2TB?, der Mouse
      • Re: partitioning >2TB?, Greg Oster
      • Re: partitioning >2TB?, Joerg Sonnenberger
• Is this assertion still correct?, Reinoud Zandijk
  • Re: Is this assertion still correct?, Andrew Doran
• "Monitoring" proplib's memory consumption, Arnaud Lacombe
• Reducing AES tables spaces, Arnaud Lacombe
  • Re: Reducing AES tables spaces, Matt Thomas
    • Re: Reducing AES tables spaces, der Mouse
    • Re: Reducing AES tables spaces, Arnaud Lacombe
• Kernel Single-user Memory usage breakdown results , Juha Keski-Saari
  • Re: Kernel Single-user Memory usage breakdown resu, Mindaugas Rasiukevicius
    • RE: Kernel Single-user Memory usage breakdown resu, Juha Keski-Saari
      • Re: Kernel Single-user Memory usage breakdown resu, Juha Keski-Saari
• ksyms_init considered too heavyweight for early bo, Martin Husemann
  • Re: ksyms_init considered too heavyweight for earl, Andrew Doran
  • Re: ksyms_init considered too heavyweight for earl, Michael
  • Re: ksyms_init considered too heavyweight for earl, Martin Husemann
    • Re: ksyms_init considered too heavyweight for earl, Martin Husemann
      • Re: ksyms_init considered too heavyweight for earl, Andrew Doran
      • Re: ksyms_init considered too heavyweight for earl, Martin Husemann
      • re: ksyms_init considered too heavyweight for earl, matthew green
      • Re: ksyms_init considered too heavyweight for earl, Martin Husemann
      • Re: ksyms_init considered too heavyweight for earl, Martin Husemann
• interface detach/destroy hook?, der Mouse
  • Re: interface detach/destroy hook?, Joerg Sonnenberger
    • Re: interface detach/destroy hook?, der Mouse
      • Re: interface detach/destroy hook?, Martin Husemann
      • Re: interface detach/destroy hook?, der Mouse
      • Re: interface detach/destroy hook?, Joerg Sonnenberger
• Re: Using qsort(3) in the kernel, kamel derouiche
• Using qsort(3) in the kernel (was: CVS commit: src, Matthias Scheler
  • Re: Using qsort(3) in the kernel (was: CVS commit:, Andrew Doran
    • Re: Using qsort(3) in the kernel, Johnny Billquist
  • Re: Using qsort(3) in the kernel (was: CVS commit:, kamel derouiche
    • Re: Using qsort(3) in the kernel (was: CVS commit:, Steven M. Bellovin
      • Re: Using qsort(3) in the kernel (was: CVS commit:, Martin S. Weber
      • Re: Using qsort(3) in the kernel, Anders Magnusson
      • Re: Using qsort(3) in the kernel, Martin S. Weber
      • Re: Using qsort(3) in the kernel, David Holland
      • Re: Using qsort(3) in the kernel, David Laight
      • Re: Using qsort(3) in the kernel, Ignatios Souvatzis
      • Re: Using qsort(3) in the kernel, Johnny Billquist
      • Re: Using qsort(3) in the kernel, Johnny Billquist
      • Re: Using qsort(3) in the kernel, Steven M. Bellovin
      • Re: Using qsort(3) in the kernel, Johnny Billquist
      • Re: Using qsort(3) in the kernel, Matt Thomas
      • Re: Using qsort(3) in the kernel, Andrew Reilly
      • Re: Using qsort(3) in the kernel, Johnny Billquist
      • Re: Using qsort(3) in the kernel, Matt Thomas
      • Re: Using qsort(3) in the kernel, Johnny Billquist
  • Re: Using qsort(3) in the kernel (was: CVS commit:, Joerg Sonnenberger
    • Re: Using qsort(3) in the kernel (was: CVS commit:, Martin S. Weber
    • Re: Using qsort(3) in the kernel, Aleksey Cheusov
    • Re: Using qsort(3) in the kernel (was: CVS commit:, Andrew Doran
• options RND_COM considered dangeous, Rafal Boni
  • Re: options RND_COM considered dangeous, Daniel Carosone
    • Re: options RND_COM considered dangeous, Andrew Doran
• Re: Lastest WAPBL update destroys the root partiti, Michael
  • Re: Lastest WAPBL update destroys the root partiti, Joerg Sonnenberger
    • Re: Lastest WAPBL update destroys the root partiti, Michael
      • Re: Lastest WAPBL update destroys the root partiti, Joerg Sonnenberger
      • Re: Lastest WAPBL update destroys the root partiti, Michael
      • Re: Lastest WAPBL update destroys the root partiti, Joerg Sonnenberger
      • Re: Lastest WAPBL update destroys the root partiti, Michael
      • Re: Lastest WAPBL update destroys the root partiti, Joerg Sonnenberger
      • Re: Lastest WAPBL update destroys the root partiti, Michael
      • Re: Lastest WAPBL update destroys the root partiti, Michael
    • Re: Lastest WAPBL update destroys the root partiti, Bernd Ernesti
• RFC: generic notification mechanism, Christoph Egger
  • Re: RFC: generic notification mechanism, Antti Kantee
    • Re: RFC: generic notification mechanism, Christoph Egger
• TP4 over IP and EON support to be removed in -curr, Matt Thomas
  • Re: TP4 over IP and EON support to be removed in -, Antti Kantee
  • Re: TP4 over IP and EON support to be removed in -, Ignatios Souvatzis
    • Re: TP4 over IP and EON support to be removed in -, Nick Hudson
      • Re: TP4 over IP and EON support to be removed in -, Antti Kantee
      • Re: TP4 over IP and EON support to be removed in -, Ignatios Souvatzis
      • Re: TP4 over IP and EON support to be removed in -, Johnny Billquist
      • Re: TP4 over IP and EON support to be removed in -, Robert Elz
      • Re: TP4 over IP and EON support to be removed in -, Christos Zoulas
• modules in -current, Alexander Shishkin
  • Re: modules in -current, Andy Shevchenko
• Path to kmods, Mindaugas Rasiukevicius
  • Re: Path to kmods, Andrew Doran
    • Re: Path to kmods, Hubert Feyrer
      • Re: Path to kmods, vincent
      • Re: Path to kmods, Michael