Re: 9.0 bata2 keymap

2011-09-24 Thread Fbsd8

Gavin Atkinson wrote:

On Sat, 2011-09-17 at 12:24 -0400, Fbsd8 wrote:

Changing the cancel button in the kbdmap command to skip, does not 
address the problem, which is the lack of knowledge of the standard 
bsdinstall user. I've been using Freebsd since 4.0 and never used the 
kbdmap command or for that matter even knew it existed.


Interesting.  Sysinstall has asked for country information and then
asked you to choose a keymap (using kbdmap) if you selected a
non-default country as the first two questions (i.e. before you get the
sysinstall menu) since 6.1.  Would that be a good solution still?

Some of the other points brought up later about wanting to switch
between two different keymaps seem sensible too, though I don't
initially see how that would be possible.

Gavin



In sysinstall you are presented with a dailog that asks you if you want 
to change the keyboard map and if answered yes them issues the kbdmap 
command. In bsdinstall you have no option to bypass the keymap step. It 
just issues the kbdmap command. I agree that some method to bypass the 
keymap step in bsdinstall needs to be added or an dialog informing the 
user that selecting the cancel button in kbdmap will result in the 
default map used in previous releases to be used.

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


Re: SCSI descriptor sense changes, testing needed

2011-09-24 Thread Fabian Keil
Kenneth D. Merry k...@freebsd.org wrote:

 I have attached a set of patches against head that implement SCSI
 descriptor sense support for CAM.

 Anyway, I'd appreciate any testing and feedback on these changes.  As I
 said, they will probably be in 9.0, so if there are any issues it would
 be better to find them now. :)

I've been using the patch on a ThinkPad R500 since yesterday and
just reverted it today again to get my kernel closer to HEAD before
looking into some (probably unrelated) panics.

I didn't notice it while using the patch, but it looks like the
kernel wasn't able to pick up cd0 anymore:

fk@r500 ~ $grep -h new dis /var/log/messages /var/log/messages.[123] | sort
Sep 21 23:40:23 r500 kernel: GEOM: new disk da0
Sep 21 23:40:30 r500 kernel: GEOM: new disk da1
Sep 21 23:45:21 r500 kernel: GEOM: new disk ada0
Sep 21 23:45:21 r500 kernel: GEOM: new disk cd0
Sep 21 23:45:21 r500 kernel: GEOM: new disk da0
Sep 21 23:45:21 r500 kernel: GEOM: new disk da1
Sep 21 23:52:44 r500 kernel: GEOM: new disk ada0
Sep 21 23:52:44 r500 kernel: GEOM: new disk cd0
Sep 21 23:53:14 r500 kernel: GEOM: new disk da0
Sep 21 23:56:23 r500 kernel: GEOM: new disk da1
Sep 22 21:14:17 r500 kernel: GEOM: new disk ada0
Sep 22 21:14:17 r500 kernel: GEOM: new disk cd0
Sep 22 22:10:20 r500 kernel: GEOM: new disk da0
[patch applied]
Sep 22 23:29:45 r500 kernel: GEOM: new disk da0
Sep 23 14:38:31 r500 kernel: GEOM: new disk ada0
Sep 23 17:19:40 r500 kernel: GEOM: new disk da0
Sep 23 19:20:21 r500 kernel: GEOM: new disk da0
Sep 23 19:20:42 r500 kernel: GEOM: new disk da1
Sep 23 22:58:56 r500 kernel: GEOM: new disk da0
Sep 24 09:31:02 r500 kernel: GEOM: new disk ada0
Sep 24 14:17:22 r500 kernel: GEOM: new disk da0
Sep 24 14:44:03 r500 kernel: GEOM: new disk ada0
Sep 24 14:44:03 r500 kernel: GEOM: new disk da0
Sep 24 14:53:30 r500 kernel: GEOM: new disk ada0
Sep 24 15:03:24 r500 kernel: GEOM: new disk da0
Sep 24 15:06:03 r500 kernel: GEOM: new disk da0
Sep 24 15:13:57 r500 kernel: GEOM: new disk ada0
Sep 24 15:14:16 r500 kernel: GEOM: new disk da0
Sep 24 15:27:11 r500 kernel: GEOM: new disk ada0
Sep 24 15:28:05 r500 kernel: GEOM: new disk da0
Sep 24 15:32:10 r500 kernel: GEOM: new disk ada0
Sep 24 15:32:10 r500 kernel: GEOM: new disk da0
Sep 24 15:38:16 r500 kernel: GEOM: new disk ada0
Sep 24 15:38:16 r500 kernel: GEOM: new disk da0
Sep 24 15:43:33 r500 kernel: GEOM: new disk ada0
Sep 24 15:43:33 r500 kernel: GEOM: new disk da0
Sep 24 15:49:30 r500 kernel: GEOM: new disk ada0
[patch reverted]
Sep 24 19:32:51 r500 kernel: GEOM: new disk ada0
Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0
Sep 24 19:32:51 r500 kernel: GEOM: new disk da0
Sep 24 19:38:07 r500 kernel: GEOM: new disk ada0
Sep 24 19:38:07 r500 kernel: GEOM: new disk cd0

Without the patch I'm used to getting the following kernel
messages when booting (without a disc in cd0):

Sep 24 19:32:51 r500 kernel: ahcich0: AHCI reset: device ready after 100ms
Sep 24 19:32:51 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: 
Sep 24 19:32:51 r500 kernel: ahcich1: AHCI reset: device ready after 100ms
Sep 24 19:32:51 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14
Sep 24 19:32:51 r500 kernel: GEOM: new disk cd0
Sep 24 19:32:51 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0
Sep 24 19:32:51 r500 kernel: pass0: HITACHI HTS543225L9SA00 FBEZC4EC ATA-8 
SATA 1.x device
Sep 24 19:32:51 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A
Sep 24 19:32:51 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 
8192bytes)
Sep 24 19:32:51 r500 kernel: pass0: Command Queueing enabled
Sep 24 19:32:51 r500 kernel: pass1 at ahcich1 bus 0 scbus1 target 0 lun 0
Sep 24 19:32:51 r500 kernel: pass1: HL-DT-ST DVDRAM GSA-T50N RX05 Removable 
CD-ROM SCSI-0 device 
Sep 24 19:32:51 r500 kernel: pass1: Serial Number M2R96NC0647
Sep 24 19:32:51 r500 kernel: pass1: 150.000MB/s transfers (SATA 1.x, UDMA6, 
ATAPI 12bytes, PIO 8192bytes)
Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error
Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 
0 0 0 0 0 0 
Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error
Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condition
Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: UNIT ATTENTION 
asc:29,0 (Power on, reset, or bus device reset occurred)
Sep 24 19:32:51 r500 kernel: (cd0:ahcich1:0:0:0): Retrying command (per sense 
data)
Sep 24 19:32:51 r500 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
Sep 24 19:32:51 r500 kernel: ada0: HITACHI HTS543225L9SA00 FBEZC4EC ATA-8 
SATA 1.x device
Sep 24 19:32:51 r500 kernel: ada0: Serial Number 090509FB2F32LLEY6D8A
Sep 24 19:32:51 r500 kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 
8192bytes)
Sep 24 19:32:51 r500 kernel: ada0: Command Queueing enabled
Sep 24 19:32:51 r500 kernel: ada0: 238475MB (488397168 512 byte sectors: 16H 
63S/T 16383C)
Sep 24 19:32:51 r500 kernel: ada0: Previously was 

Re: 9.0 bata2 keymap

2011-09-24 Thread Adrian Chadd
On 25 September 2011 01:30, Fbsd8 fb...@a1poweruser.com wrote:

 In sysinstall you are presented with a dailog that asks you if you want to
 change the keyboard map and if answered yes them issues the kbdmap command.
 In bsdinstall you have no option to bypass the keymap step. It just issues
 the kbdmap command. I agree that some method to bypass the keymap step in
 bsdinstall needs to be added or an dialog informing the user that selecting
 the cancel button in kbdmap will result in the default map used in previous
 releases to be used.

That sounds sensible. It's all just bourne shell script, right? Would
you mind doing up a patch to do that?



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


Re: 9.0 bata2 keymap

2011-09-24 Thread Fbsd8

Adrian Chadd wrote:

On 25 September 2011 01:30, Fbsd8 fb...@a1poweruser.com wrote:


In sysinstall you are presented with a dailog that asks you if you want to
change the keyboard map and if answered yes them issues the kbdmap command.
In bsdinstall you have no option to bypass the keymap step. It just issues
the kbdmap command. I agree that some method to bypass the keymap step in
bsdinstall needs to be added or an dialog informing the user that selecting
the cancel button in kbdmap will result in the default map used in previous
releases to be used.


That sounds sensible. It's all just bourne shell script, right? Would
you mind doing up a patch to do that?



Adrian



http://www.freebsd.org/cgi/query-pr.cgi?pr=160913

Heres the pr.


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