8.1-STABLE: zfs and sendfile: problem still exists

2010-10-27 Thread Alexander Zagrebin
Hi!

I've noticed that ZFS on 8.1-STABLE still has problems with sendfile.
When accessing a file at first time the transfer speed is too low, but
on following attempts the transfer speed is normal.

How to repeat:

$ dd if=/dev/random of=/tmp/test bs=1m count=100
100+0 records in
100+0 records out
104857600 bytes transferred in 5.933945 secs (17670807 bytes/sec)
$ sudo env LC_ALL=C /usr/libexec/ftpd -D

The first attempt to fetch file:

$ fetch -o /dev/null ftp://localhost/tmp/test
/dev/null   1% of  100 MB  118 kBps
14m07s^C
fetch: transfer interrupted

The transfer rate is too low (approx. 120 kBps), but any subsequent attempts
are success:

$ fetch -o /dev/null ftp://localhost/tmp/test
/dev/null 100% of  100 MB   42 MBps
$ fetch -o /dev/null ftp://localhost/tmp/test
/dev/null 100% of  100 MB   47 MBps
...

To repeat it is enough to copy a file and to try again:

$ cp /tmp/test /tmp/test1
$ fetch -o /dev/null ftp://localhost/tmp/test1
/dev/null   2% of  100 MB  119 kBps
13m50s^C
fetch: transfer interrupted
$ fetch -o /dev/null ftp://localhost/tmp/test1
/dev/null 100% of  100 MB   41 MBps
$ fetch -o /dev/null ftp://localhost/tmp/test1
/dev/null 100% of  100 MB   47 MBps

...and again:

$ cp /tmp/test1 /tmp/test2
$ fetch -o /dev/null ftp://localhost/tmp/test2
/dev/null   1% of  100 MB  118 kBps
14m07s^C
fetch: transfer interrupted
$ fetch -o /dev/null ftp://localhost/tmp/test2
/dev/null 100% of  100 MB   41 MBps
$ fetch -o /dev/null ftp://localhost/tmp/test2
/dev/null 100% of  100 MB   47 MBps

I've tried ftpd and nginx with "sendfile on". The behavior is the same.
After disabling using sendfile in nginx ("sendfile off") the problem has
gone.

-- 
Alexander Zagrebin

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Degraded zpool cannot detach old/bad drive

2010-10-27 Thread Rumen Telbizov
Thanks Artem,

I am mainly concerned about fixing this immediate problem first and then if
I
can provide more information for the developers so that they look into this
problem
I'd be happy to.

I'll try OpenSolaris live CD and see how it goes. Either way I'll report
back here.

Cheers,
Rumen Telbizov

On Wed, Oct 27, 2010 at 5:22 PM, Artem Belevich  wrote:

> Are you interested in what's wrong or in how to fix it?
>
> If fixing is the priority, I'd boot from OpenSolaris live CD and would
> try importing the array there. Just make sure you don't upgrade ZFS to
> a version that is newer than the one FreeBSD supports.
>
> Opensolaris may be able to fix the array. Once it's done, export it,
> boot back to FreeBSD and re-import it.
>
> --Artem
>
>
>
> On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov 
> wrote:
> > No ideas whatsoever?
> >
> > On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov 
> wrote:
> >
> >> Hello everyone,
> >>
> >> After a few days of struggle with my degraded zpool on a backup server I
> >> decided to ask for
> >> help here or at least get some clues as to what might be wrong with it.
> >> Here's the current state of the zpool:
> >>
> >> # zpool status
> >>
> >>   pool: tank
> >>  state: DEGRADED
> >> status: One or more devices has experienced an error resulting in data
> >> corruption.  Applications may be affected.
> >> action: Restore the file in question if possible.  Otherwise restore the
> >> entire pool from backup.
> >>see: http://www.sun.com/msg/ZFS-8000-8A
> >>  scrub: none requested
> >> config:
> >>
> >> NAME  STATE READ WRITE CKSUM
> >> tank  DEGRADED 0 0 0
> >>   raidz1  DEGRADED 0 0 0
> >> spare DEGRADED 0 0 0
> >>   replacing   DEGRADED 0 0 0
> >> 17307041822177798519  UNAVAIL  0   299 0  was
> >> /dev/gpt/disk-e1:s2
> >> gpt/newdisk-e1:s2 ONLINE   0 0 0
> >>   gpt/disk-e2:s10 ONLINE   0 0 0
> >> gpt/disk-e1:s3ONLINE  30 0 0
> >> gpt/disk-e1:s4ONLINE   0 0 0
> >> gpt/disk-e1:s5ONLINE   0 0 0
> >>   raidz1  ONLINE   0 0 0
> >> gpt/disk-e1:s6ONLINE   0 0 0
> >> gpt/disk-e1:s7ONLINE   0 0 0
> >> gpt/disk-e1:s8ONLINE   0 0 0
> >> gpt/disk-e1:s9ONLINE   0 0 0
> >>   raidz1  ONLINE   0 0 0
> >> gpt/disk-e1:s10   ONLINE   0 0 0
> >> gpt/disk-e1:s11   ONLINE   0 0 0
> >> gpt/disk-e1:s12   ONLINE   0 0 0
> >> gpt/disk-e1:s13   ONLINE   0 0 0
> >>   raidz1  DEGRADED 0 0 0
> >> gpt/disk-e1:s14   ONLINE   0 0 0
> >> gpt/disk-e1:s15   ONLINE   0 0 0
> >> gpt/disk-e1:s16   ONLINE   0 0 0
> >> spare DEGRADED 0 0 0
> >>   replacing   DEGRADED 0 0 0
> >> 15258738282880603331  UNAVAIL  048 0  was
> >> /dev/gpt/disk-e1:s17
> >> gpt/newdisk-e1:s17ONLINE   0 0 0
> >>   gpt/disk-e2:s11 ONLINE   0 0 0
> >>   raidz1  ONLINE   0 0 0
> >> gpt/disk-e1:s18   ONLINE   0 0 0
> >> gpt/disk-e1:s19   ONLINE   0 0 0
> >> gpt/disk-e1:s20   ONLINE   0 0 0
> >> gpt/disk-e1:s21   ONLINE   0 0 0
> >>   raidz1  ONLINE   0 0 0
> >> gpt/disk-e1:s22   ONLINE   0 0 0
> >> gpt/disk-e1:s23   ONLINE   0 0 0
> >> gpt/disk-e2:s0ONLINE   0 0 0
> >> gpt/disk-e2:s1ONLINE   0 0 0
> >>   raidz1  ONLINE   0 0 0
> >> gpt/disk-e2:s2ONLINE   0 0 0
> >> gpt/disk-e2:s3ONLINE   0 0 0
> >> gpt/disk-e2:s4ONLINE   0 0 0
> >> gpt/disk-e2:s5ONLINE   0 0 0
> >>   raidz1  ONLINE   0 0 0
> >> gpt/disk-e2:s6ONLINE   0 0 0
> >> gpt/disk-e2:s7ONLINE   0 0 0
> >>  

Re: Degraded zpool cannot detach old/bad drive

2010-10-27 Thread Artem Belevich
Are you interested in what's wrong or in how to fix it?

If fixing is the priority, I'd boot from OpenSolaris live CD and would
try importing the array there. Just make sure you don't upgrade ZFS to
a version that is newer than the one FreeBSD supports.

Opensolaris may be able to fix the array. Once it's done, export it,
boot back to FreeBSD and re-import it.

--Artem



On Wed, Oct 27, 2010 at 4:22 PM, Rumen Telbizov  wrote:
> No ideas whatsoever?
>
> On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov  wrote:
>
>> Hello everyone,
>>
>> After a few days of struggle with my degraded zpool on a backup server I
>> decided to ask for
>> help here or at least get some clues as to what might be wrong with it.
>> Here's the current state of the zpool:
>>
>> # zpool status
>>
>>   pool: tank
>>  state: DEGRADED
>> status: One or more devices has experienced an error resulting in data
>>         corruption.  Applications may be affected.
>> action: Restore the file in question if possible.  Otherwise restore the
>>         entire pool from backup.
>>    see: http://www.sun.com/msg/ZFS-8000-8A
>>  scrub: none requested
>> config:
>>
>>         NAME                          STATE     READ WRITE CKSUM
>>         tank                          DEGRADED     0     0     0
>>           raidz1                      DEGRADED     0     0     0
>>             spare                     DEGRADED     0     0     0
>>               replacing               DEGRADED     0     0     0
>>                 17307041822177798519  UNAVAIL      0   299     0  was
>> /dev/gpt/disk-e1:s2
>>                 gpt/newdisk-e1:s2     ONLINE       0     0     0
>>               gpt/disk-e2:s10         ONLINE       0     0     0
>>             gpt/disk-e1:s3            ONLINE      30     0     0
>>             gpt/disk-e1:s4            ONLINE       0     0     0
>>             gpt/disk-e1:s5            ONLINE       0     0     0
>>           raidz1                      ONLINE       0     0     0
>>             gpt/disk-e1:s6            ONLINE       0     0     0
>>             gpt/disk-e1:s7            ONLINE       0     0     0
>>             gpt/disk-e1:s8            ONLINE       0     0     0
>>             gpt/disk-e1:s9            ONLINE       0     0     0
>>           raidz1                      ONLINE       0     0     0
>>             gpt/disk-e1:s10           ONLINE       0     0     0
>>             gpt/disk-e1:s11           ONLINE       0     0     0
>>             gpt/disk-e1:s12           ONLINE       0     0     0
>>             gpt/disk-e1:s13           ONLINE       0     0     0
>>           raidz1                      DEGRADED     0     0     0
>>             gpt/disk-e1:s14           ONLINE       0     0     0
>>             gpt/disk-e1:s15           ONLINE       0     0     0
>>             gpt/disk-e1:s16           ONLINE       0     0     0
>>             spare                     DEGRADED     0     0     0
>>               replacing               DEGRADED     0     0     0
>>                 15258738282880603331  UNAVAIL      0    48     0  was
>> /dev/gpt/disk-e1:s17
>>                 gpt/newdisk-e1:s17    ONLINE       0     0     0
>>               gpt/disk-e2:s11         ONLINE       0     0     0
>>           raidz1                      ONLINE       0     0     0
>>             gpt/disk-e1:s18           ONLINE       0     0     0
>>             gpt/disk-e1:s19           ONLINE       0     0     0
>>             gpt/disk-e1:s20           ONLINE       0     0     0
>>             gpt/disk-e1:s21           ONLINE       0     0     0
>>           raidz1                      ONLINE       0     0     0
>>             gpt/disk-e1:s22           ONLINE       0     0     0
>>             gpt/disk-e1:s23           ONLINE       0     0     0
>>             gpt/disk-e2:s0            ONLINE       0     0     0
>>             gpt/disk-e2:s1            ONLINE       0     0     0
>>           raidz1                      ONLINE       0     0     0
>>             gpt/disk-e2:s2            ONLINE       0     0     0
>>             gpt/disk-e2:s3            ONLINE       0     0     0
>>             gpt/disk-e2:s4            ONLINE       0     0     0
>>             gpt/disk-e2:s5            ONLINE       0     0     0
>>           raidz1                      ONLINE       0     0     0
>>             gpt/disk-e2:s6            ONLINE       0     0     0
>>             gpt/disk-e2:s7            ONLINE       0     0     0
>>             gpt/disk-e2:s8            ONLINE       0     0     0
>>             gpt/disk-e2:s9            ONLINE       0     0     0
>>         spares
>>           gpt/disk-e2:s10             INUSE     currently in use
>>           gpt/disk-e2:s11             INUSE     currently in use
>>           gpt/disk-e1:s2              UNAVAIL   cannot open
>>           gpt/newdisk-e1:s17          INUSE     currently in use
>>
>> errors: 4 data errors, use '-v' for a list
>>
>>
>> The problem is: after replacing the bad drives and resilveri

Re: Degraded zpool cannot detach old/bad drive

2010-10-27 Thread Rumen Telbizov
No ideas whatsoever?

On Tue, Oct 26, 2010 at 1:04 PM, Rumen Telbizov  wrote:

> Hello everyone,
>
> After a few days of struggle with my degraded zpool on a backup server I
> decided to ask for
> help here or at least get some clues as to what might be wrong with it.
> Here's the current state of the zpool:
>
> # zpool status
>
>   pool: tank
>  state: DEGRADED
> status: One or more devices has experienced an error resulting in data
> corruption.  Applications may be affected.
> action: Restore the file in question if possible.  Otherwise restore the
> entire pool from backup.
>see: http://www.sun.com/msg/ZFS-8000-8A
>  scrub: none requested
> config:
>
> NAME  STATE READ WRITE CKSUM
> tank  DEGRADED 0 0 0
>   raidz1  DEGRADED 0 0 0
> spare DEGRADED 0 0 0
>   replacing   DEGRADED 0 0 0
> 17307041822177798519  UNAVAIL  0   299 0  was
> /dev/gpt/disk-e1:s2
> gpt/newdisk-e1:s2 ONLINE   0 0 0
>   gpt/disk-e2:s10 ONLINE   0 0 0
> gpt/disk-e1:s3ONLINE  30 0 0
> gpt/disk-e1:s4ONLINE   0 0 0
> gpt/disk-e1:s5ONLINE   0 0 0
>   raidz1  ONLINE   0 0 0
> gpt/disk-e1:s6ONLINE   0 0 0
> gpt/disk-e1:s7ONLINE   0 0 0
> gpt/disk-e1:s8ONLINE   0 0 0
> gpt/disk-e1:s9ONLINE   0 0 0
>   raidz1  ONLINE   0 0 0
> gpt/disk-e1:s10   ONLINE   0 0 0
> gpt/disk-e1:s11   ONLINE   0 0 0
> gpt/disk-e1:s12   ONLINE   0 0 0
> gpt/disk-e1:s13   ONLINE   0 0 0
>   raidz1  DEGRADED 0 0 0
> gpt/disk-e1:s14   ONLINE   0 0 0
> gpt/disk-e1:s15   ONLINE   0 0 0
> gpt/disk-e1:s16   ONLINE   0 0 0
> spare DEGRADED 0 0 0
>   replacing   DEGRADED 0 0 0
> 15258738282880603331  UNAVAIL  048 0  was
> /dev/gpt/disk-e1:s17
> gpt/newdisk-e1:s17ONLINE   0 0 0
>   gpt/disk-e2:s11 ONLINE   0 0 0
>   raidz1  ONLINE   0 0 0
> gpt/disk-e1:s18   ONLINE   0 0 0
> gpt/disk-e1:s19   ONLINE   0 0 0
> gpt/disk-e1:s20   ONLINE   0 0 0
> gpt/disk-e1:s21   ONLINE   0 0 0
>   raidz1  ONLINE   0 0 0
> gpt/disk-e1:s22   ONLINE   0 0 0
> gpt/disk-e1:s23   ONLINE   0 0 0
> gpt/disk-e2:s0ONLINE   0 0 0
> gpt/disk-e2:s1ONLINE   0 0 0
>   raidz1  ONLINE   0 0 0
> gpt/disk-e2:s2ONLINE   0 0 0
> gpt/disk-e2:s3ONLINE   0 0 0
> gpt/disk-e2:s4ONLINE   0 0 0
> gpt/disk-e2:s5ONLINE   0 0 0
>   raidz1  ONLINE   0 0 0
> gpt/disk-e2:s6ONLINE   0 0 0
> gpt/disk-e2:s7ONLINE   0 0 0
> gpt/disk-e2:s8ONLINE   0 0 0
> gpt/disk-e2:s9ONLINE   0 0 0
> spares
>   gpt/disk-e2:s10 INUSE currently in use
>   gpt/disk-e2:s11 INUSE currently in use
>   gpt/disk-e1:s2  UNAVAIL   cannot open
>   gpt/newdisk-e1:s17  INUSE currently in use
>
> errors: 4 data errors, use '-v' for a list
>
>
> The problem is: after replacing the bad drives and resilvering the old/bad
> drives cannot be detached.
> The replace command didn't remove it automatically and manual detach fails.
> Here are some examples:
>
> # zpool detach tank 15258738282880603331
> cannot detach 15258738282880603331: no valid replicas
> # zpool detach tank gpt/disk-e2:s11
> cannot detach gpt/disk-e2:s11: no valid replicas
> # zpool detach tank gpt/newdisk-e1:s17
> cannot detach gpt/newdisk-e1:s17: no valid replicas
> # zpool detach tank gpt/disk-e1:s17
> cannot detach gpt/disk-e1:s17: no valid repli

Re: ZFS write speed

2010-10-27 Thread Stefan Bethke
Am 27.10.2010 um 22:51 schrieb S.N.Grigoriev:

> Hi list,
> 
> I've got very low write speed using ZFS on a SATA disk.
> My HDD configuration is:
> ad4: 70911MB  at ata2-master UDMA100 SATA 3Gb/s
> ad6: 78532MB  at ata3-master UDMA100 SATA 
> 1.5Gb/s
> ad8: 1430799MB  at ata4-master UDMA100 SATA 
> 3Gb/s

The EARS has 4k sectors, if I'm not mistaken.  I don't recall the eventual 
outcome, but there was a long thread on stable or hackers on how to ensure 
proper alignment and (minimun) 4k-sized writes to make sure the disk doesn't 
have to do a read-modify-write cycle, so try and search the archives.

> ad4 and ad6 are single-slice disks (UFS2 with soft updates)
> 
> ZFS configuration is following:
> zpool create Z ad8
> zfs create Z/music
> zfs create Z/video
> All ZFS parameters are default.
> kern.maxvnodes = 100
> 
> To test my configuration I recursively copied from ad6 to ad8 two directories.
> The first one contains MP3 files (average size = 10MB).
> The second one contains AVI files (average size = 1GB). 
> 
> To compare performance I repeated above tests with ad8 using UFS2 with soft 
> updates.
> 
> 18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS.
> 30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS.
> 
> I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB.
> 
> Any tips?
> 
> -- 
> Regards,
> Serguey.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 
Stefan BethkeFon +49 151 14070811



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: cdrtools /devel and wodim broken

2010-10-27 Thread Jakub Lach


Sean C. Farley-2 wrote:
> 
> For me, the solution appeared to be setting the grace time to three 
> seconds to avoid the slowdown of the drive:  gracetime=3
> At least, the disc worked on subsequent burns this way.  Jakub, you may 
> try to see if this setting helps.
> 

No, gracetime doesn't help. Maybe Alexander Motin could 
shed some light on (ahci?) problem?

thanks for assistance, 
Jakub Lach

-- 
View this message in context: 
http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p30071221.html
Sent from the freebsd-stable mailing list archive at Nabble.com.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


ZFS write speed

2010-10-27 Thread S . N . Grigoriev
Hi list,

I've got very low write speed using ZFS on a SATA disk.
My HDD configuration is:
ad4: 70911MB  at ata2-master UDMA100 SATA 3Gb/s
ad6: 78532MB  at ata3-master UDMA100 SATA 
1.5Gb/s
ad8: 1430799MB  at ata4-master UDMA100 SATA 3Gb/s
ad4 and ad6 are single-slice disks (UFS2 with soft updates)

ZFS configuration is following:
zpool create Z ad8
zfs create Z/music
zfs create Z/video
All ZFS parameters are default.
kern.maxvnodes = 100

To test my configuration I recursively copied from ad6 to ad8 two directories.
The first one contains MP3 files (average size = 10MB).
The second one contains AVI files (average size = 1GB). 

To compare performance I repeated above tests with ad8 using UFS2 with soft 
updates.

18GB of MP3 files required 10m35s to copy to UFS2 and 21m40s to copy to ZFS.
30GB of AVI files required 16m6s to copy to UFS2 and 1h2m39s to copy to ZFS.

I used for tests FreeBSD 8.1R amd64. Amount of RAM on my machine is 6GB.

Any tips?

-- 
Regards,
Serguey.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: beastiality

2010-10-27 Thread Randy Bush
> This is often caused by a combination of two things being enabled
> simultaneously: BIOS-level serial console redirection after POST, and
> FreeBSD's serial console support.

bingo!

thanks

randy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: beastiality

2010-10-27 Thread Jeremy Chadwick
On Thu, Oct 28, 2010 at 04:47:00AM +0900, Randy Bush wrote:
> on the serial console, i am seeing twirlies doubled, as in
> 
> //
> 
> and the beastie is very tortured
> 
>  
> +-++¿Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä|Ä-Ä
>   ||³
>  ||³   ||³ ,, ,,  
>||³,, ||³/()`  
> //(( ||³Welcome to FreeBSD!oo  FFrr|BSSDD!!   \ \___   / 
> |  \\  \\___||³  //  ||   ||³/- _  
> `-/  '  //--  __ ||³``--//''   ||³   (/\/ 
> \ \   /\((//\\//  \||³1. Boot FreeBSD [default]BSSDD  [[ddeef|aauulltt]]   / 
> /   | `\/  // ||³2. Boot FreeBSD with ACPI enabledwiitth|  AACCPPII  
> eennaab) /|/|||³3. Boot FreeBSD in Safe ModeDD  iinn  S|a 
>`-^--'`< '`--^^'||³4. Boot FreeBSD in single user moden  s|i   
> (_.)  _  )   /ddee))_||³5. Boot FreeBSD with verbose loggingtth|  
>`.___/`/   /||³6. Escape to loader promptllooaaddeerr |p   
>`-' /  ``-||³7. Rebootebbtt || 
> <. __ / __   \    //  _||³  \\   
> || <|O)))==) \) /|))))||³\\))  //||   
>   || <'`--' `.__,' \`''  ``.||³__,,''  \\ 
> ||  || || ||³||   
>   ||   \   /   /\   ||³Select option, [Enter] for 
> defaultEnntt|e  __( (_  / \__/_(( ||³or [Space] to pause 
> timer  H--11  ussee| ,'  ,-'   |  
> ,,-+-++
> `--{__) -Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä_))  
>
> [...]
> spare.psg.com:/root# cat /boot/loader.conf.local
> loader_logo=beastie
> #
> console="comconsole vidconsole"
> comconsole_speed="9600"
> #
> ipfw_load=YES

This is often caused by a combination of two things being enabled
simultaneously: BIOS-level serial console redirection after POST, and
FreeBSD's serial console support.  Effectively, the system BIOS is
"redirecting" VGA output to the serial port, while simultaneously
FreeBSD is doing serial console.

But I've seen different behaviour on different hardware over the years
when the first option is enabled.

- "Doubling of characters" like the above (but sometimes not doubled)
- System hard locking (reset/power cycle required) the instant the boot
  loader tries to do serial (some of my Yahoo! colleagues can confirm
  this one, even when using RedHat)
- System boots/runs fine but no serial output is visible past loader

I have some older Supermicro systems which do even weirder things when
the option is enabled, like lock up after loader.  I've also see
different behaviour on RELENG_7 than I do RELENG_8.

Back to Supermicro systems -- the aforementioned feature is usually
labelled as "Continue C.R. After POST" (C.R. stands for Console
Redirection).  This is not the same thing as disabling BIOS-level serial
console entirely, just that the "Agent" (some sort of interrupt tie-in)
isn't retained after POST.

If your system offers the BIOS option, you can try turning it off and
see if things improve.  Be aware that you will lose the ability to
access things like Option ROMs (SCSI BIOSes, Intel NIC PXE boot
information, etc.).

If your system doesn't offer that BIOS option, then possibly just
leaving console as its default will suffice.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


beastiality

2010-10-27 Thread Randy Bush
on the serial console, i am seeing twirlies doubled, as in

//

and the beastie is very tortured

 
+-++¿Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä|Ä-Ä
  ||³
 ||³   ||³ ,, ,,
 ||³,, ||³/()`  //((
 ||³Welcome to FreeBSD!oo  FFrr|BSSDD!!   \ \___   / |  \\  
\\___||³  //  ||   ||³/- _  `-/  '  
//--  __ ||³``--//''   ||³   (/\/ \ \   
/\((//\\//  \||³1. Boot FreeBSD [default]BSSDD  [[ddeef|aauulltt]]   / /   | `  
  \/  // ||³2. Boot FreeBSD with ACPI enabledwiitth|  AACCPPII  eennaab) /  
  |/|||³3. Boot FreeBSD in Safe ModeDD  iinn  S|a`-^--'`<   
  '`--^^'||³4. Boot FreeBSD in single user moden  s|i   (_.)  _  )  
 /ddee))_||³5. Boot FreeBSD with verbose loggingtth| `.___/`
/   /||³6. Escape to loader promptllooaaddeerr |p  `-' 
/  ``-||³7. Rebootebbtt || <. __ / __   
\    //  _||³  \\   || <|O)))==) \) 
/|))))||³\\))  //|| || <'`--' 
`.__,' \`''  ``.||³__,,''  \\ ||  | 
   | || ||³|| ||   
\   /   /\   ||³Select option, [Enter] for defaultEnntt|e  
__( (_  / \__/_(( ||³or [Space] to pause timer  H--11  ussee| 
,'  ,-'   |  ,,-+-++
`--{__) -Ä-Ä-Ä-Ä-Ä-Ä-Ä-Ä_))  
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.1-STABLE #1: Sun Sep  5 12:04:21 GMT 2010
r...@test.psg.com:/usr/obj/usr/src/sys/SPARE i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.67-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  Family = f  Model = 2  Stepping = 7
  Features=0xbfebfbffhttp://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: hast vs ggate+gmirror sychrnoisation speed

2010-10-27 Thread Mikolaj Golub

On Tue, 26 Oct 2010 17:01:01 +0100 Pete French wrote:

 PF>  Actually, I just llooked I dmesg on the secondary - it is full
 PF> of messages thus:

 PF> Oct 26 15:44:59 serpentine-passive hastd[10394]: [serp0] (secondary) 
Unable to receive request header: RPC version wrong.
 PF> Oct 26 15:45:00 serpentine-passive hastd[782]: [serp0] (secondary) Worker 
process exited ungracefully (pid=10394, exitcode=75).
 PF> Oct 26 15:46:59 serpentine-passive hastd[10421]: [serp0] (secondary) 
Unable to receive request header: RPC version wrong.
 PF> Oct 26 15:47:04 serpentine-passive hastd[782]: [serp0] (secondary) Worker 
process exited ungracefully (pid=10421, exitcode=75).

I saw this too but only sporadic messages so I forgot and did not investigate
then this :-).

Now running synchronization I see them too (but again only sporadic). Setting
the assertion and looking at the received header:

(gdb) list
309 goto fail;
310
311 if (hdr.version != HAST_PROTO_VERSION) {
312 assert(0);
313 errno = ERPCMISMATCH;
314 goto fail;
315 }
316
317 hdr.size = le32toh(hdr.size);
318
(gdb) p/x hdr
$2 = {version = 0x9, size = 0x65657266}

So it looks like garbage.

In hast_proto_send() we send header and then data. Couldn't it be that
remote_send and sync threads interfere and their packets are mixed? May be some
synchronization is needed here?

I set sleep(1) in hast_proto_send() between proto_send(header) and
proto_send(data). The error started to occur frequently.

-- 
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Can't build boot blocks after new GPT attributes added

2010-10-27 Thread Dag-Erling Smørgrav
Jeremy Chadwick  writes:
> $ uname -a
> FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 
> PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64  
> amd64
> $ sudo -i
> icarus# rm -fr /usr/obj/*
> rm: No match.
> icarus# cd /usr/src

icarus# make toolchain

> icarus# make buildenv
> Entering world for amd64:amd64
> # make clean && make
> [...]

FTFY.  HTH, HAND!

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Can't build boot blocks after new GPT attributes added

2010-10-27 Thread Pawel Jakub Dawidek
On Wed, Oct 27, 2010 at 06:48:58AM -0700, Jeremy Chadwick wrote:
> On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote:
> > On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote:
> > > The below commit has broken the ability to build system boot blocks
> > > (including pxeldr) the "historic way"[1]:
> > > 
> > > http://freshbsd.org/2010/10/17/20/10/00
> > > 
> > > The breakage on RELENG_8 (dated as of a few minutes ago):
> > > 
> > > 
> > > # rm -fr /usr/obj/*
> > > # cd /sys/boot
> > > # make clean
> > 
> > This only works if your source tree is in sync with your installed world.  
> > Adding a hack to the Makefile is wrong.  The buildenv approach pjd@ 
> > suggested 
> > will work for the case that your source tree does not match your installed 
> > world.
> 
> But this doesn't appear to be the case here:
[...]

Because you don't have toolchain built. Once you buildworld you can do
that. All in all, the safest and most recommended way is to just use
buildworld/buildkernel.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgppZbOHEKVga.pgp
Description: PGP signature


Re: Can't build boot blocks after new GPT attributes added

2010-10-27 Thread Jeremy Chadwick
On Wed, Oct 27, 2010 at 09:27:03AM -0400, John Baldwin wrote:
> On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote:
> > The below commit has broken the ability to build system boot blocks
> > (including pxeldr) the "historic way"[1]:
> > 
> > http://freshbsd.org/2010/10/17/20/10/00
> > 
> > The breakage on RELENG_8 (dated as of a few minutes ago):
> > 
> > 
> > # rm -fr /usr/obj/*
> > # cd /sys/boot
> > # make clean
> 
> This only works if your source tree is in sync with your installed world.  
> Adding a hack to the Makefile is wrong.  The buildenv approach pjd@ suggested 
> will work for the case that your source tree does not match your installed 
> world.

But this doesn't appear to be the case here:

$ uname -a
FreeBSD icarus.home.lan 8.1-STABLE FreeBSD 8.1-STABLE #0: Sat Oct 16 07:10:54 
PDT 2010 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64  
amd64
$ sudo -i
icarus# rm -fr /usr/obj/*
rm: No match.
icarus# cd /usr/src
icarus# make buildenv
Entering world for amd64:amd64
# make clean && make
[...]
cc -DBOOTPROG=\"gptboot\"  -Os  -fno-guess-branch-probability  
-fomit-frame-pointer  -fno-unit-at-a-time  -mno-align-long-strings  -mrtd  
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3  -DGPT  -DUFS1_AND_UFS2  
-DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600  
-I/usr/src/sys/boot/i386/gptboot/../../common  
-I/usr/src/sys/boot/i386/gptboot/../common  
-I/usr/src/sys/boot/i386/gptboot/../btx/lib -I.  
-I/usr/src/sys/boot/i386/gptboot/../boot2  -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align  -Wmissing-declarations -Wmissing-prototypes 
-Wnested-externs  -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings  
-Winline --param max-inline-insns-single=100 -ffreestanding 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-m32 -march=i386 -std=gnu99   -c 
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind':
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 
'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared 
identifier is reported only once
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function 
it appears in.)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 
'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed':
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 
'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 
'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv':
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 
'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 
'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 
'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
*** Error code 1

Stop in /usr/src/sys/boot/i386/gptboot.
*** Error code 1

Stop in /usr/src/sys/boot/i386.
*** Error code 1

Stop in /usr/src/sys/boot.
# ls -l /usr/src/sys/boot/i386/gptboot/../../common/gpt.c
-rw-r--r--  1 root  wheel  10927 Oct 17 13:10 
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c

Any ideas?

> Maybe you could add text to the handbook to say this, but it is already 
> implicitly assumed in the handbook section you are referring to since it 
> assumes you can safely compile a new kernel, etc.  The handbook section is 
> meant as more of a tutorial on how to enable a serial console on a fresh box. 
>  
> Once you are experienced enough to start using buildworld, etc. I don't think 
> it is unreasonable to require users to understand that having a source tree 
> different from the installed world requires extra steps.

I don't think it's unreasonable either, it's just not well-documented or
well-established.  For example, this is the first time I've heard of
"buildenv", not to mention the other pieces mentioned in build(7).  That
doesn't mean FreeBSD is at fault, it just means there's been changes to
things which are hard to keep up to date on.

> If we were to document those every time it would clutter documentation
> making it harder for someone who is new to FreeBSD to simply setup a
> serial console on a box that they just installed.

Understood.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

_

Re: Can't build boot blocks after new GPT attributes added

2010-10-27 Thread John Baldwin
On Wednesday, October 27, 2010 3:44:02 am Jeremy Chadwick wrote:
> The below commit has broken the ability to build system boot blocks
> (including pxeldr) the "historic way"[1]:
> 
> http://freshbsd.org/2010/10/17/20/10/00
> 
> The breakage on RELENG_8 (dated as of a few minutes ago):
> 
> 
> # rm -fr /usr/obj/*
> # cd /sys/boot
> # make clean

This only works if your source tree is in sync with your installed world.  
Adding a hack to the Makefile is wrong.  The buildenv approach pjd@ suggested 
will work for the case that your source tree does not match your installed 
world.

Maybe you could add text to the handbook to say this, but it is already 
implicitly assumed in the handbook section you are referring to since it 
assumes you can safely compile a new kernel, etc.  The handbook section is 
meant as more of a tutorial on how to enable a serial console on a fresh box.  
Once you are experienced enough to start using buildworld, etc. I don't think 
it is unreasonable to require users to understand that having a source tree 
different from the installed world requires extra steps.  If we were to 
document those every time it would clutter documentation making it harder for 
someone who is new to FreeBSD to simply setup a serial console on a box that 
they just installed.

-- 
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Can't build boot blocks after new GPT attributes added

2010-10-27 Thread Andriy Gapon
on 27/10/2010 12:17 Jeremy Chadwick said the following:
> On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote:
>> The proper way is to:
>>
>>  # cd /usr/src
>>  # make buildenv
>>  # cd sys/boot
>>  # make clean && make && make install
> 
> Thanks for the tip -- the CFLAGS change in a Makefile sounds like the
> solution, since the latter (re: "proper way") didn't work (exact same
> problem).

The above will work if you already have the toolchain built - that's the only 
way
to ensure that you don't depend on anything in the currently installed world.
See build(7).

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Can't build boot blocks after new GPT attributes added

2010-10-27 Thread Jeremy Chadwick
On Wed, Oct 27, 2010 at 10:08:17AM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote:
> > The below commit has broken the ability to build system boot blocks
> > (including pxeldr) the "historic way"[1]:
> > 
> > http://freshbsd.org/2010/10/17/20/10/00
> > 
> > The breakage on RELENG_8 (dated as of a few minutes ago):
> > 
> > 
> > # rm -fr /usr/obj/*
> > # cd /sys/boot
> > # make clean
> > [...]
> > # make
> > [...]
> > cc -DBOOTPROG=\"gptboot\"  -Os  -fno-guess-branch-probability  
> > -fomit-frame-pointer  -fno-unit-at-a-time  -mno-align-long-strings  -mrtd  
> > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3  -DGPT  -DUFS1_AND_UFS2  
> > -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600  
> > -I/usr/src/sys/boot/i386/gptboot/../../common  
> > -I/usr/src/sys/boot/i386/gptboot/../common  
> > -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I.  
> > -I/usr/src/sys/boot/i386/gptboot/../boot2  -Wall -Waggregate-return 
> > -Wbad-function-cast -Wcast-align  -Wmissing-declarations 
> > -Wmissing-prototypes -Wnested-externs  -Wpointer-arith -Wshadow 
> > -Wstrict-prototypes -Wwrite-strings  -Winline --param 
> > max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2  
> > -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 
> > -std=gnu99   -c /usr/src/sys/boot/i386/gptboot/../../common/gpt.c
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind':
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 
> > 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each 
> > undeclared identifier is reported only once
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each 
> > function it appears in.)
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 
> > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 
> > 'gptbootfailed':
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 
> > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 
> > 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 
> > 'gptbootconv':
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 
> > 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 
> > 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
> > /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 
> > 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
> > *** Error code 1
> > 
> > Stop in /usr/src/sys/boot/i386/gptboot.
> > *** Error code 1
> > 
> > Stop in /usr/src/sys/boot/i386.
> > *** Error code 1
> > 
> > Stop in /usr/src/sys/boot.
> > 
> > 
> > Please advise.  If there is a new/correct method, then I'd like to know
> > what it is, in addition to the Handbook needing to be updated.
> > 
> > [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html
> >  (See Section 26.6.5.2)
> 
> Well, your problem is that gptboot.c is including gpt.h not from your
> source tree, but from /usr/include/sys/, which has an old version of
> this header file. This can be easly fixed by extending CFLAGS in one of
> the Makefiles (which is already done in HEAD), but I'm afraid this
> procedure is incorrect (and never was correct). Apart from including
> wrong files it also links to wrong libraries, etc.
> 
> The proper way is to:
> 
>   # cd /usr/src
>   # make buildenv
>   # cd sys/boot
>   # make clean && make && make install

Thanks for the tip -- the CFLAGS change in a Makefile sounds like the
solution, since the latter (re: "proper way") didn't work (exact same
problem).  The Makefile adjustment you mention for HEAD is here:

http://freshbsd.org/2010/10/08/10/27/52

But there's no mention of an MFC date in the commit message.  Can this
be MFC'd?

For now, "make buildworld" works as a workaround (pull the bootstrap
binaries needed out of /usr/obj).

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Can't build boot blocks after new GPT attributes added

2010-10-27 Thread Pawel Jakub Dawidek
On Wed, Oct 27, 2010 at 12:44:02AM -0700, Jeremy Chadwick wrote:
> The below commit has broken the ability to build system boot blocks
> (including pxeldr) the "historic way"[1]:
> 
> http://freshbsd.org/2010/10/17/20/10/00
> 
> The breakage on RELENG_8 (dated as of a few minutes ago):
> 
> 
> # rm -fr /usr/obj/*
> # cd /sys/boot
> # make clean
> [...]
> # make
> [...]
> cc -DBOOTPROG=\"gptboot\"  -Os  -fno-guess-branch-probability  
> -fomit-frame-pointer  -fno-unit-at-a-time  -mno-align-long-strings  -mrtd  
> -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3  -DGPT  -DUFS1_AND_UFS2  
> -DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600  
> -I/usr/src/sys/boot/i386/gptboot/../../common  
> -I/usr/src/sys/boot/i386/gptboot/../common  
> -I/usr/src/sys/boot/i386/gptboot/../btx/lib -I.  
> -I/usr/src/sys/boot/i386/gptboot/../boot2  -Wall -Waggregate-return 
> -Wbad-function-cast -Wcast-align  -Wmissing-declarations -Wmissing-prototypes 
> -Wnested-externs  -Wpointer-arith -Wshadow -Wstrict-prototypes 
> -Wwrite-strings  -Winline --param max-inline-insns-single=100 -ffreestanding 
> -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 
> -mno-sse3 -m32 -march=i386 -std=gnu99   -c 
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind':
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 
> 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each 
> undeclared identifier is reported only once
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each 
> function it appears in.)
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 
> 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 
> 'gptbootfailed':
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 
> 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 
> 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv':
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 
> 'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 
> 'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
> /usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 
> 'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
> *** Error code 1
> 
> Stop in /usr/src/sys/boot/i386/gptboot.
> *** Error code 1
> 
> Stop in /usr/src/sys/boot/i386.
> *** Error code 1
> 
> Stop in /usr/src/sys/boot.
> 
> 
> Please advise.  If there is a new/correct method, then I'd like to know
> what it is, in addition to the Handbook needing to be updated.
> 
> [1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html
>  (See Section 26.6.5.2)

Well, your problem is that gptboot.c is including gpt.h not from your
source tree, but from /usr/include/sys/, which has an old version of
this header file. This can be easly fixed by extending CFLAGS in one of
the Makefiles (which is already done in HEAD), but I'm afraid this
procedure is incorrect (and never was correct). Apart from including
wrong files it also links to wrong libraries, etc.

The proper way is to:

# cd /usr/src
# make buildenv
# cd sys/boot
# make clean && make && make install

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgpGuoEb8uCVg.pgp
Description: PGP signature


Can't build boot blocks after new GPT attributes added

2010-10-27 Thread Jeremy Chadwick
The below commit has broken the ability to build system boot blocks
(including pxeldr) the "historic way"[1]:

http://freshbsd.org/2010/10/17/20/10/00

The breakage on RELENG_8 (dated as of a few minutes ago):


# rm -fr /usr/obj/*
# cd /sys/boot
# make clean
[...]
# make
[...]
cc -DBOOTPROG=\"gptboot\"  -Os  -fno-guess-branch-probability  
-fomit-frame-pointer  -fno-unit-at-a-time  -mno-align-long-strings  -mrtd  
-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3  -DGPT  -DUFS1_AND_UFS2  
-DSIOPRT=0x3f8  -DSIOFMT=0x3  -DSIOSPD=9600  
-I/usr/src/sys/boot/i386/gptboot/../../common  
-I/usr/src/sys/boot/i386/gptboot/../common  
-I/usr/src/sys/boot/i386/gptboot/../btx/lib -I.  
-I/usr/src/sys/boot/i386/gptboot/../boot2  -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align  -Wmissing-declarations -Wmissing-prototypes 
-Wnested-externs  -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings  
-Winline --param max-inline-insns-single=100 -ffreestanding 
-mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 
-m32 -march=i386 -std=gnu99   -c 
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptfind':
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: 
'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: (Each undeclared 
identifier is reported only once
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:128: error: for each function 
it appears in.)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:130: error: 
'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootfailed':
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:217: error: 
'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:222: error: 
'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c: In function 'gptbootconv':
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:249: error: 
'GPT_ENT_ATTR_BOOTME' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:250: error: 
'GPT_ENT_ATTR_BOOTONCE' undeclared (first use in this function)
/usr/src/sys/boot/i386/gptboot/../../common/gpt.c:251: error: 
'GPT_ENT_ATTR_BOOTFAILED' undeclared (first use in this function)
*** Error code 1

Stop in /usr/src/sys/boot/i386/gptboot.
*** Error code 1

Stop in /usr/src/sys/boot/i386.
*** Error code 1

Stop in /usr/src/sys/boot.


Please advise.  If there is a new/correct method, then I'd like to know
what it is, in addition to the Handbook needing to be updated.

[1]: http://www.freebsd.org/doc/handbook/serialconsole-setup.html
 (See Section 26.6.5.2)

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://www.parodius.com/ |
| UNIX Systems Administrator  Mountain View, CA, USA |
| Making life hard for others since 1977.  PGP: 4BD6C0CB |

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"