ChangeLog Thu Sep 11 00:49:16 CDT 2008

[phobos3576]

Ho notato che Pat è rimasto al 2.6.24.7; non posso che condividere questa scelta visti i problemi che, dal 2.6.25 in su, si stanno manifestando, soprattutto sull'hardware meno recente.
Analizzando il codice sorgente ho notato che, a partire dal 2.6.25, tutto il supporto USB è stato completamente stravolto; il risultato è che, come risulta leggendo anche le mailing list di www.kernel.org, molte periferiche USB hanno smesso di funzionare!
Nel mio caso, i problemi si manifestano sul card reader integrato nella stampante HP; ho provato numerose distribuzioni Live e, in tutti i casi, solo con il kernel 2.6.24.x il card reader funziona.

[JohnnyMnemonic]

Io sto usando l'ultimo kernel rilasciato stable e l'unico problema che ho è il microfono della scheda audio che non funziona correttamente, un giro dl alsaconf e va tutto a posto, ma bisogna farlo dopo ogni riavvio

Comunque leggendo il Changelog Patrick sta aspettando che il ramo .26 si assesti per fare il passaggio

[conraid]

Che usb avrebbe avuto dei problemi era messo in preventivo con la scelta dei soli driver free. Però in effetti, anche se utilizzo il .26 sul fisso ed il .25 sul notebook (altrimenti si blocca al riconoscimento della scheda wireless) il .24 è l'unico che mi fa andare bene la scheda wireless stessa.
Dal .25 in poi anche se no è acceso, lui lo considera acceso, ed al boot cerca la rete... e naturalmente poi da errore perchè non trova nemmeno la scheda.
con il .24 tutto ok
Solo che dal 25 hanno sistemato molte cose che mi servivano tipo i tasti per lo schermo e il microfono che con il .24 non funziona

Va beh... non capisco però la cosa del wireless, una palla enorme

[phobos3576]

Solo che dal 25 hanno sistemato molte cose che mi servivano ...

Il problema è proprio quello!
Con i 2.6.25.x e 2.6.26.x buona parte dell'hardware funziona molto meglio; per alcune periferiche però succede esattamente il contrario.

[navajo]

Non capisco come si possa in una versione nuova del kernel, aggiustare una cosa e rovinare ciò che andava...
Tutto questo mi riporta indietro a un certo flame sulla necessità di aggiornare continuamente un kernel, senza un motivo valido... vabbÈ

[Blizzard]

Non capisco come si possa in una versione nuova del kernel, aggiustare una cosa e rovinare ciò che andava...
Tutto questo mi riporta indietro a un certo flame sulla necessità di aggiornare continuamente un kernel, senza un motivo valido... vabbÈ

ma ciò che andava (ed ora non va più) era grazie ai driver proprietari vero????

[conraid]

Non capisco come si possa in una versione nuova del kernel, aggiustare una cosa e rovinare ciò che andava...
Tutto questo mi riporta indietro a un certo flame sulla necessità di aggiornare continuamente un kernel, senza un motivo valido... vabbÈ

ma ciò che andava (ed ora non va più) era grazie ai driver proprietari vero????

No, per esempio per intel wireless è questione di modifiche al core ed alla parte rf_kill. Se hanno migliorato molti aspetti, purtroppo in alcuni casi ne hanno peggiorati altri. In pratica hanno quasi riscritto buona parte del codice

[Blizzard]

Non capisco come si possa in una versione nuova del kernel, aggiustare una cosa e rovinare ciò che andava...
Tutto questo mi riporta indietro a un certo flame sulla necessità di aggiornare continuamente un kernel, senza un motivo valido... vabbÈ

ma ciò che andava (ed ora non va più) era grazie ai driver proprietari vero????

No, per esempio per intel wireless è questione di modifiche al core ed alla parte rf_kill. Se hanno migliorato molti aspetti, purtroppo in alcuni casi ne hanno peggiorati altri. In pratica hanno quasi riscritto buona parte del codice

Capito!
beh il refactoring è comunque una cosa importante... speriamo che correggano presto.

[Vito]

Non capisco come si possa in una versione nuova del kernel, aggiustare una cosa e rovinare ciò che andava...
Tutto questo mi riporta indietro a un certo flame sulla necessità di aggiornare continuamente un kernel, senza un motivo valido... vabbÈ

ma ciò che andava (ed ora non va più) era grazie ai driver proprietari vero????

No, per esempio per intel wireless è questione di modifiche al core ed alla parte rf_kill. Se hanno migliorato molti aspetti, purtroppo in alcuni casi ne hanno peggiorati altri. In pratica hanno quasi riscritto buona parte del codice

Sul mio Notebook con il .24 non ho problemi con la scheda wireless,mentre col .26 dopo 3secondi la linea cade!La scheda è una Intel...

[phobos3576]

Non capisco come si possa in una versione nuova del kernel, aggiustare una cosa e rovinare ciò che andava...
Tutto questo mi riporta indietro a un certo flame sulla necessità di aggiornare continuamente un kernel, senza un motivo valido... vabbÈ

A me a volte viene voglia di scrivere qualche e-mail di protesta a quelli di kernel.org; il problema è che poi mi risponde Linus Torvalds con la solita frase: "you are full of bullshit"!

Questo, ad esempio, è un estratto del file transport.c relativo all'emulazione SCSI del supporto USB sul 2.6.24.x, quando tutto funzionava perfettamente:

Codice: Seleziona tutto

/* try to compute the actual residue, based on how much data
	 * was really transferred and what the device tells us */
	if (residue) {
		if (!(us->flags & US_FL_IGNORE_RESIDUE)) {
			residue = min(residue, transfer_length);
			srb->resid = max(srb->resid, (int) residue);
		}
	}

Poi qualcuno ha deciso che, siccome funzionava tutto bene, bisognava stravolgere il codice in questo modo (notate la nuova funzione scsi_set_resid):

Codice: Seleziona tutto

/* try to compute the actual residue, based on how much data
	 * was really transferred and what the device tells us */
	if (residue) {
		if (!(us->flags & US_FL_IGNORE_RESIDUE)) {
			residue = min(residue, transfer_length);
			scsi_set_resid(srb, max(scsi_get_resid(srb),
			                                       (int) residue));
		}
	}

Dopo questo stravolgimento, molte periferiche USB hanno smesso di funzionare, per cui il precedente codice è stato grossolanamente patchato in questo modo:

Codice: Seleziona tutto

/* try to compute the actual residue, based on how much data
	 * was really transferred and what the device tells us */
	if (residue && !(us->flags & US_FL_IGNORE_RESIDUE)) {

		/* Heuristically detect devices that generate bogus residues
		 * by seeing what happens with INQUIRY and READ CAPACITY
		 * commands.
		 */
		if (bcs->Status == US_BULK_STAT_OK &&
				scsi_get_resid(srb) == 0 &&
					((srb->cmnd[0] == INQUIRY &&
						transfer_length == 36) ||
					(srb->cmnd[0] == READ_CAPACITY &&
						transfer_length == 8))) {
			us->flags |= US_FL_IGNORE_RESIDUE;

		} else {
			residue = min(residue, transfer_length);
			scsi_set_resid(srb, max(scsi_get_resid(srb),
			                                       (int) residue));
		}
	}

Non sono certo un kernel hacker, però vedendo queste cose ho l'impressione che in certi casi lo sviluppo del kernel proceda in modo piuttosto avventato!

[slucky]

voi pensate che nella prossima release di Slackware ci sarà kde 4 come de di default o ancora la serie 3.5?
nel mio piccolo, visto che avevo scaricato la current, l'ho provata per curiosità....e devo dire che Pat è il suo staff hanno già fatto un gran lavoro, eccetto qualche problemino di gioventù con il desktop e con la rete wpa poi risolto...ho trovato un sistema già perfettamente usabile e completo molto migliore di altre distro che già implementano kde4...


saluti a tutti

[Blizzard]

Non capisco come si possa in una versione nuova del kernel, aggiustare una cosa e rovinare ciò che andava...
Tutto questo mi riporta indietro a un certo flame sulla necessità di aggiornare continuamente un kernel, senza un motivo valido... vabbÈ

A me a volte viene voglia di scrivere qualche e-mail di protesta a quelli di kernel.org; il problema è che poi mi risponde Linus Torvalds con la solita frase: "you are full of bullshit"!

Questo, ad esempio, è un estratto del file transport.c relativo all'emulazione SCSI del supporto USB sul 2.6.24.x, quando tutto funzionava perfettamente:

Codice: Seleziona tutto

/* try to compute the actual residue, based on how much data
	 * was really transferred and what the device tells us */
	if (residue) {
		if (!(us->flags & US_FL_IGNORE_RESIDUE)) {
			residue = min(residue, transfer_length);
			srb->resid = max(srb->resid, (int) residue);
		}
	}

Poi qualcuno ha deciso che, siccome funzionava tutto bene, bisognava stravolgere il codice in questo modo (notate la nuova funzione scsi_set_resid):

Codice: Seleziona tutto

/* try to compute the actual residue, based on how much data
	 * was really transferred and what the device tells us */
	if (residue) {
		if (!(us->flags & US_FL_IGNORE_RESIDUE)) {
			residue = min(residue, transfer_length);
			scsi_set_resid(srb, max(scsi_get_resid(srb),
			                                       (int) residue));
		}
	}

Dopo questo stravolgimento, molte periferiche USB hanno smesso di funzionare, per cui il precedente codice è stato grossolanamente patchato in questo modo:

Codice: Seleziona tutto

/* try to compute the actual residue, based on how much data
	 * was really transferred and what the device tells us */
	if (residue && !(us->flags & US_FL_IGNORE_RESIDUE)) {

		/* Heuristically detect devices that generate bogus residues
		 * by seeing what happens with INQUIRY and READ CAPACITY
		 * commands.
		 */
		if (bcs->Status == US_BULK_STAT_OK &&
				scsi_get_resid(srb) == 0 &&
					((srb->cmnd[0] == INQUIRY &&
						transfer_length == 36) ||
					(srb->cmnd[0] == READ_CAPACITY &&
						transfer_length == 8))) {
			us->flags |= US_FL_IGNORE_RESIDUE;

		} else {
			residue = min(residue, transfer_length);
			scsi_set_resid(srb, max(scsi_get_resid(srb),
			                                       (int) residue));
		}
	}

Non sono certo un kernel hacker, però vedendo queste cose ho l'impressione che in certi casi lo sviluppo del kernel proceda in modo piuttosto avventato!

humm...
nei primi casi quando si verificava

if (residue) {
if (!(us->flags & US_FL_IGNORE_RESIDUE)) {
...

srb->resid veniva settato ad un qualcosa
anche con le funzioni set/get il codice in teoria non era affatto cambiato (quindi IMHO il problema era nella set/get)

nell'ultimo caso, anche se si verifica che US_FL_IGNORE_RESIDUE==0 il residuo può essere ignorato nel caso si verifichino le condizioni

if (bcs->Status == US_BULK_STAT_OK &&
scsi_get_resid(srb) == 0 &&
((srb->cmnd[0] == INQUIRY &&
transfer_length == 36) ||
(srb->cmnd[0] == READ_CAPACITY &&
transfer_length == )) {
....

mmm... da quello che ho capito tentano di evitare l'esplosione del codice tentando di individuare una certa condizione che pensano che lo faccia crashare ed evitando che in quelle condizioni il codice di scsi_set_residue venga eseguito.

Humm... questa è IMHO forte!!!

Gio

[Blizzard]

adesso mi chiedo...
ma il flag
us->flags |= US_FL_IGNORE_RESIDUE;
viene risettato da qualche parte a 0???
non è che tipo si verifica quella condizione del mega IF e poi non c'è un caso che lo risetta a 0 e ci sono problemoni?
Tenete presente che nei primi codici non era previsto all'interno di quell'if di settare a 0/1 quel flag.

Al massimo I'm full of bullshit!

[Bart]

voi pensate che nella prossima release di Slackware ci sarà kde 4 come de di default o ancora la serie 3.5?
nel mio piccolo, visto che avevo scaricato la current, l'ho provata per curiosità....e devo dire che Pat è il suo staff hanno già fatto un gran lavoro, eccetto qualche problemino di gioventù con il desktop e con la rete wpa poi risolto...ho trovato un sistema già perfettamente usabile e completo molto migliore di altre distro che già implementano kde4...


saluti a tutti

Io credo proprio di no, kde4 è ancora troppo giovane per sostituire la 3.5.x IMHO.
Probabilmente rimarrà in testing per parecchio. Più che crederlo me lo auguro vista la reputazione di questa distro.

[Loris]

La penso come Bart, io vedo una 13.0 con kde 3* e una futura 13.1 con il 4*