announce: C Conference CFP closing June 7th
The first ever "C Conference" is happening August 28th, 2012 in San Diego, CA. The target audience are people who implement systems in C. Whether that be new languages, libraries, kernels, daemons or games. A reverse call for papers is up and closes June 7th. Submit talks you would like to give or talks you want to see given. Either way! Early bird tickets are available for $225. If you plan to attend LinuxCon/CloudOpen the following day you can get a package with C Conf and LinuxCon/CloudOpen for $520 (LinuxCon/CloudOpen are $500 alone). http://cconf.org Hope to see you there. Email me if you have any questions! Brandon
mg - more emacs scroll compatibility
Show a message and beep when you reach either end of a buffer.
ok?
-lum
Index: basic.c
===
RCS file: /cvs/src/usr.bin/mg/basic.c,v
retrieving revision 1.33
diff -u -p -r1.33 basic.c
--- basic.c 31 May 2012 10:55:53 - 1.33
+++ basic.c 31 May 2012 14:54:24 -
@@ -269,8 +269,11 @@ forwpage(int f, int n)
lp = curwp->w_linep;
while (n--)
- if ((lp = lforw(lp)) == curbp->b_headp)
+ if ((lp = lforw(lp)) == curbp->b_headp) {
+ ttbeep();
+ ewprintf("End of buffer");
return(TRUE);
+ }
curwp->w_linep = lp;
curwp->w_rflag |= WFFULL;
@@ -314,6 +317,10 @@ backpage(int f, int n)
while (n-- && lback(lp) != curbp->b_headp) {
lp = lback(lp);
+ }
+ if (lp == curwp->w_linep) {
+ ttbeep();
+ ewprintf("Beginning of buffer");
}
curwp->w_linep = lp;
curwp->w_rflag |= WFFULL;
Re: Realtek RTS5209 (was: Re: Intel AHCI RAID controller in Sony VAIO Z23 laptop)
On Thu, 31 May 2012, Stefan Sperling wrote: >On Thu, May 31, 2012 at 10:53:22AM +0200, Paul de Weerd wrote: >> I've recently bought a new Sony laptop, VPCZ23C5E. Some things on >> this machine work fine (sound, suspend, wired network), some things >> don't (X, resume, wireless). > >I suppose the card reader won't work either: > >> "Realtek RTS5209 Card Reader" rev 0x01 at pci2 dev 0 function 0 not >> configured > >I have exactly this chip in a new laptop and am trying to write a driver >for it based on information from the linux driver. >I haven't got it working yet but I'll send you a diff once I have >something to show. > >It's not an easy task for me and progress is somewhat slower than >I expected so if anyone wants to help that would be great. I've got one of those too, and can help with testing and perhaps in other ways: while I've no experience (other than some code-reading) with BSD internals I have done driver/internals work on a couple of other systems. Dave -- Dave Anderson
Re: Intel AHCI RAID controller in Sony VAIO Z23 laptop
On Thu, May 31, 2012 at 10:53 +0200, Paul de Weerd wrote:
> I've recently bought a new Sony laptop, VPCZ23C5E. Some things on
> this machine work fine (sound, suspend, wired network), some things
> don't (X, resume, wireless). One of the problems I have is that
> -current doesn't find any disks behind the pciide(4), which is a
> "Intel 82081HBM RAID". sthen@ suggested I revert 1.163 of
> dev/pci/ahci.c, which was the clue I needed to getting things working.
>
> I built a kernel with the following diff applied:
>
> Index: ahci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/ahci.c,v
> retrieving revision 1.188
> diff -u -r1.188 ahci.c
> --- ahci.c5 May 2012 10:10:12 - 1.188
> +++ ahci.c31 May 2012 08:19:39 -
> @@ -504,6 +504,8 @@
> NULL, ahci_intel_attach },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_AHCI,
> NULL, ahci_intel_attach },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
> + NULL, ahci_intel_attach },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_AHCI_1,
> NULL, ahci_intel_attach },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_AHCI_2,
>
> Now, the controller attaches as ahci(4) and disks are found behind it.
> Here's the relevant portion of the diff between the before and after
> dmesg:
>
> -pciide0 at pci0 dev 31 function 2 "Intel 82081HBM RAID" rev 0x04: DMA,
> channel 0 wired to native-PCI, channel 1 wired to native-PCI
> -pciide0: using apic 0 int 22 for native-PCI interrupt
> +ahci0 at pci0 dev 31 function 2 "Intel 82081HBM RAID" rev 0x04: msi, AHCI 1.3
> +scsibus0 at ahci0: 32 targets
> +sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct
> fixed naa.5f0043584d30
> +sd0: 61057MB, 512 bytes/sector, 125045424 sectors, thin
> +sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct
> fixed naa.5f0043584d30
> +sd1: 61057MB, 512 bytes/sector, 125045424 sectors, thin
>
> The BIOS on this machine does not offer any settings for configuring
> the mode the controller is set to, nor does the "RAID controller BIOS"
> (which I used to move from 'raid-0' to no raid) allow me to set it as
> a 'regular' AHCI controller.
>
> So, I'd very much like to see the above diff (or something like it) go
> in, but it basically undoes the 1.163 revision which wasn't commited
> without a reason of course. Any ideas what the best solution would be
> here ?
>
> Included below are dmesgs from the non-working snapshot (April 24th
> snap), which was installed to a umass sd; the dmesg from the new
> kernel (with the diff above applied); pcidump -vx output and sysctl hw
> output.
>
> Paul 'WEiRD' de Weerd
>
>
well, this is indeed an ID of a mobile SATA controller in the RAID mode.
the only reason to undo that revision just for 82801HBM_RAID would be
because it's a mobile version and laptop bioses are too crippled to allow
users to change the mode themselves.
Re: Realtek RTS5209 (was: Re: Intel AHCI RAID controller in Sony VAIO Z23 laptop)
Hi Stefan, On Thu, May 31, 2012 at 11:20:19AM +0200, Stefan Sperling wrote: | On Thu, May 31, 2012 at 10:53:22AM +0200, Paul de Weerd wrote: | > I've recently bought a new Sony laptop, VPCZ23C5E. Some things on | > this machine work fine (sound, suspend, wired network), some things | > don't (X, resume, wireless). | | I suppose the card reader won't work either: | | > "Realtek RTS5209 Card Reader" rev 0x01 at pci2 dev 0 function 0 not configured I have to admit I haven't tried this yet. Too many things aren't working on this machine currently, the SD card reader would be nice to have, but definitely isn't at the top of the list for me ;) The real issue (at least, for me) is the Sandy Bridge video - it doesn't work with X (yet) and it turns out that it is responsible for the non-working resume (resume works fine except for video; I can blindly reboot the machine) | I have exactly this chip in a new laptop and am trying to write a driver | for it based on information from the linux driver. | I haven't got it working yet but I'll send you a diff once I have | something to show. Would be happy to try it out! Thanks, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Realtek RTS5209 (was: Re: Intel AHCI RAID controller in Sony VAIO Z23 laptop)
On Thu, May 31, 2012 at 10:53:22AM +0200, Paul de Weerd wrote: > I've recently bought a new Sony laptop, VPCZ23C5E. Some things on > this machine work fine (sound, suspend, wired network), some things > don't (X, resume, wireless). I suppose the card reader won't work either: > "Realtek RTS5209 Card Reader" rev 0x01 at pci2 dev 0 function 0 not configured I have exactly this chip in a new laptop and am trying to write a driver for it based on information from the linux driver. I haven't got it working yet but I'll send you a diff once I have something to show. It's not an easy task for me and progress is somewhat slower than I expected so if anyone wants to help that would be great.
Intel AHCI RAID controller in Sony VAIO Z23 laptop
I've recently bought a new Sony laptop, VPCZ23C5E. Some things on
this machine work fine (sound, suspend, wired network), some things
don't (X, resume, wireless). One of the problems I have is that
-current doesn't find any disks behind the pciide(4), which is a
"Intel 82081HBM RAID". sthen@ suggested I revert 1.163 of
dev/pci/ahci.c, which was the clue I needed to getting things working.
I built a kernel with the following diff applied:
Index: ahci.c
===
RCS file: /cvs/src/sys/dev/pci/ahci.c,v
retrieving revision 1.188
diff -u -r1.188 ahci.c
--- ahci.c 5 May 2012 10:10:12 - 1.188
+++ ahci.c 31 May 2012 08:19:39 -
@@ -504,6 +504,8 @@
NULL, ahci_intel_attach },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_AHCI,
NULL, ahci_intel_attach },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801HBM_RAID,
+ NULL, ahci_intel_attach },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_AHCI_1,
NULL, ahci_intel_attach },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_82801I_AHCI_2,
Now, the controller attaches as ahci(4) and disks are found behind it.
Here's the relevant portion of the diff between the before and after
dmesg:
-pciide0 at pci0 dev 31 function 2 "Intel 82081HBM RAID" rev 0x04: DMA, channel
0 wired to native-PCI, channel 1 wired to native-PCI
-pciide0: using apic 0 int 22 for native-PCI interrupt
+ahci0 at pci0 dev 31 function 2 "Intel 82081HBM RAID" rev 0x04: msi, AHCI 1.3
+scsibus0 at ahci0: 32 targets
+sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct
fixed naa.5f0043584d30
+sd0: 61057MB, 512 bytes/sector, 125045424 sectors, thin
+sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct
fixed naa.5f0043584d30
+sd1: 61057MB, 512 bytes/sector, 125045424 sectors, thin
The BIOS on this machine does not offer any settings for configuring
the mode the controller is set to, nor does the "RAID controller BIOS"
(which I used to move from 'raid-0' to no raid) allow me to set it as
a 'regular' AHCI controller.
So, I'd very much like to see the above diff (or something like it) go
in, but it basically undoes the 1.163 revision which wasn't commited
without a reason of course. Any ideas what the best solution would be
here ?
Included below are dmesgs from the non-working snapshot (April 24th
snap), which was installed to a umass sd; the dmesg from the new
kernel (with the diff above applied); pcidump -vx output and sysctl hw
output.
Paul 'WEiRD' de Weerd
Full dmesg (snapshot from last month):
OpenBSD 5.1-current (GENERIC.MP) #288: Tue Apr 24 15:39:02 MDT 2012
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8501063680 (8107MB)
avail mem = 8252411904 (7870MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe6020 (18 entries)
bios0: vendor INSYDE version "R1010H5" date 07/28/2011
bios0: Sony Corporation VPCZ23C5E
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA ASF! HPET APIC MCFG SLIC WDAT SSDT BOOT SSDT ASPT
SSDT SSDT SSDT SSDT
acpi0: wakeup devices EHC1(S3) EHC2(S3) HDEF(S0) WLAN(S0) RP01(S0) RMSC(S0)
RP02(S0) NXUC(S3) RP03(S3) RLAN(S3) RP04(S3) RP07(S3) PEG0(S0) PEGP(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2794.03 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.65 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu1: 256KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.65 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu2: 256KB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2793.66 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF
cpu
Buscamos Importadores y agentes para nuestros Robots Industriales
Para: Gerente General Nuestros robots avanzados lideran el mercado de automatizacisn industrial Gracias a la combinacisn znica de: 7 Alta produccisn y autonomma 7 Tiempos de ciclos reducidos. 7 Rapido retorno de la inversisn. 7 Posibilidad de trabajar con varias referencias. 7 Gastos mmnimos de mantenimiento. 7 Facil manejo. 7 Flexibilidad al cambio de productos. Deseamos trabajar con importadores y agentes en Nuestra empresa diseqa y fabrica sistemas robotizados con aplicaciones que van desde el despaletizado, paletizado, manipulacisn, pintura hasta la soldadura. Nuestros robots estan construidos sobre plataformas de ABB, Siemens y otras marcas conocidas mundialmente. Pueden gestionar mas de 1200 ciclos por hora, y ofrecen un rendimiento mayor en comparacisn con las personas. Nuestros robots estan instalados en distintos pamses y sirven industrias como la automotriz, alimentos, productos qummicos, minerales, bebidas embotelladas, los artmculos en cajas, plasticos, procesamiento de metales, etc. Los robots permiten flexibilidad a la hora de ejecutar cualquier proceso repetitivo, de cualquier grado de precisisn y complejidad, desde la manipulacisn de botellas para encajonado, hasta la manipulacisn de elementos de grandes dimensiones (hasta 1.000 Kg.) pasando por la manipulacisn de pequeqos materiales como elementos electrsnicos. Gracias a la combinacisn znica de un mayor rendimiento y precios competitivos, hemos sido capaces de llegar a una posicisn dominante en Espaqa, asm como en otros mercados europeos. La empresa suministra actualmente mezcla de alimentos para pajaros y roedores domisticos a importadores que le venden a su vez a tiendas de animales, zoolsgicos, jardines zoolsgicos, instalaciones de animales y criadores profesionales. Si su empresa importa y distribuye productos de animales domisticos a detallistas, nuestra empresa quisiera trabajar con Usted. Si su empresa importa y distribuye maquinaria o provee servicios de ingenierma a plantas de fabricacisn, envasado y embalaje, nuestra empresa quisiera trabajar con usted. Para ver fotos y videos y obtener mayor informacisn acerca de istos productos, haga clic en el enlace: http://www.exportmatch.co.uk/ex/2847vkm_es.asp Si usted encuentra que nuestros productos pueden complementar su lmnea de negocio, yo estarma encantado de discutir csmo podrmamos trabajar juntos, asm como enviar muestras y precios. Espero con interis escuchar de usted. Atentamente, Oscar Wolff Gerente de Exportaciones os...@exportmatch.co.uk ExportMatch es una empresa de desarrollo de exportacisn en todo el mundo. 7Para ver mas ofertas de Maquinaria Industrial visite www.exportmatch.co.uk/ex/bk/machinery.asp 7Para nuestra pagina de oportunidades de negocio, visite www.exportmatch.co.uk/exporters.asp ?Interesado en el desarrollar sus ventas de exportacisn? - !Visite www.exportmatch.co.uk y Suscribirse a ExportMatch! Si usted desea no recibir mas correspondencia de nosotros haga clic sobre expo...@exportmatch.co.uk
Re: inet(3) man page: remove extra verbiage
> Date: Thu, 31 May 2012 06:09:25 +0100 > From: Jason McIntyre > > On Thu, May 31, 2012 at 12:14:54AM -0400, Lawrence Teo wrote: > > The inet(3) man page has always felt messy to me, where the words > > "function" and "routine" are used interchangeably to describe the > > various functions in inconsistent ways. This extra verbiage makes it > > somewhat harder to look up the descriptions of functions. > > > > Since it is understood that this man page describes functions, I have > > created a diff that removes those words to make it easier and quicker > > for programmers to find the info they need. > > > > Comments? Ok? > > > > Lawrence > > > > bit of a slippery slope, this one. the man pages in general use the > terms function and routine interchangeably. you can "fix" one page, but > it will have little overall difference. > > not that i'm against your diff. i'm just not sure it will have the > overall effect you want. Dunno, feels like a change just for the sake of change. Some people prefer the slightly more verbose style, where the descriptions are proper sentences that start with a capital letter. Some prefer the slightly more compact style. I don't think we are ever going to achieve consistency in style issues like that, and frankly speaking I don't think why we should. In cases like this I tend to say: if it ain't broken, don't fix it.
Re: inet(3) man page: remove extra verbiage
Hi, Lawrence Teo wrote on Thu, May 31, 2012 at 12:14:54AM -0400: > .Pp > -The > .Fn inet_aton > -routine interprets the specified character string as an Internet address, > +interprets the specified character string as an Internet address, > placing the address into the structure provided. I dislike macros at the beginnings of sentences, they prevent proper capitalization. Properly capitalized sentences read better and are easier to find in the text. When i revise a manual (for unrelated, more important reasons), i often do the reverse of what you are proposing here. Finding the functions names is not really an issue, they are set in bold face and stick out well from the text. Consistency with respect to "routine" and "function" can't hurt, in particular when writing a new manual or when revising an existing one (and i'd probably slightly prefer "function"), but i'm not sure it will be worth the effort to try to find and fix all these cases. Certainly, it shouldn't be done mechanically, there might be exceptions. Yours, Ingo
mg - scrolling back diff
Currently, mg's cursor jumps from top to bottom of the screen as you
scroll upwards, I find this behaviour confusing at times. This diff
makes mg's scroll back the same as emacs.
Comments/ok?
mark
Index: basic.c
===
RCS file: /cvs/src/usr.bin/mg/basic.c,v
retrieving revision 1.32
diff -u -p -r1.32 basic.c
--- basic.c 30 May 2012 06:13:32 - 1.32
+++ basic.c 31 May 2012 06:57:11 -
@@ -301,7 +301,7 @@ forwpage(int f, int n)
int
backpage(int f, int n)
{
- struct line *lp;
+ struct line *lp, *lp2;
if (!(f & FFARG)) {
n = curwp->w_ntrows - 2;/* Default scroll. */
@@ -309,18 +309,24 @@ backpage(int f, int n)
n = 1; /* window is tiny. */
} else if (n < 0)
return (forwpage(f | FFRAND, -n));
- lp = curwp->w_linep;
+
+ lp = lp2 = curwp->w_linep;
+
while (n-- && lback(lp) != curbp->b_headp) {
lp = lback(lp);
}
curwp->w_linep = lp;
curwp->w_rflag |= WFFULL;
+
/* if in current window, don't move dot */
for (n = curwp->w_ntrows; n-- && lp != curbp->b_headp; lp = lforw(lp))
if (lp == curwp->w_dotp)
return (TRUE);
+
+lp2 = lforw(lp2);
+
/* Move the dot the slow way, for line nos */
- while (curwp->w_dotp != curwp->w_linep) {
+ while (curwp->w_dotp != lp2) {
curwp->w_dotp = lback(curwp->w_dotp);
curwp->w_dotline--;
}
